Thursday, May 14, 2020

#SecurityStories: OWASP Virtual AppSec Days

When I heard that there will be a virtual conference by OWASP, hosted at a time I could easily join after work, I simply had to sign up. It fit too well to my personal challenge of telling #SecurityStories to let this opportunity pass by.
The OWASP Virtual AppSec Days April 2020 consisted of a free mini-conference with talks as well as two days of training, split into four hours each day. They also hosted a virtual capture the flag competition, yet I felt not ready to go full in yet.

The Talks

On the first day, three talks were presented in a row. In case you'd like to watch them yourself, their recording is available on YouTube.
  • "Building and growing an application security team - lessons from a CISO perspective" by Michael Coates. I liked this talk a lot. Nothing was really new to me, yet these important messages still need to be heard.
    • I keep finding lots of parallels when it comes to security testing and any kind of testing. In his talk, Michael made clear that it's not about eliminating all security bugs, and rather about building up risk management. There's always a healthy balance of risk in every organization. Fixing every single bug is not worth it, the effort is too high; yet we want to fix the most important ones. Sounds familiar? Here's another one: The goal is to empower business to move fast and make informed risk decisions. It's important to have both technical and business understanding. Secure code empowers the limitless exploration of technology and innovation. And another one: Put security in the hands of teams themselves instead of a security team approving something. This moves ownership of risk to the teams. If the teams know that they are responsible, it really changes their mindset. I can't agree more.
    • According to Michael's experience, a successful application security program uses a "Paved Road Approach", offering the teams an easy and secure route where they get support, and empowering them to take this route. They are not forced to, yet the incentive is high and teams usually prefer the easy way. If security issues are found, however, he advocated for taking the hard way and fixing the fundamental root cause instead of the symptoms. Make sure they cannot occur again or at least people get alerted if they do. To operate at scale, refrain from building your own solutions and rather integrate trusted existing systems. If you have a central security team, they don't own the risk, the single business units and product teams do - so they need to get the incentives to care. Last but not least, a successful program needs to be focused, prioritizing the most important risks. Every time you shift focus, you're saying that this thing is more important than what you did before.
    • When it comes to building a successful application security team, Michael emphasized the importance of senior team members letting go of easier problems and instead training less experienced people to solve them. Allow your juniors to grow, and have seniors focus on senior problems. Overall, creating a great work place where people get training as well as challenges is key. Having real one to one conversations, finding out people's motivation, encouraging them to blog, speak and contribute to open source are all parts of having the people create a great work place. We are the result of an amazing team around us.
  • "Certificate Revocation: Past, Present, Future" by Mark Goodwin. This talk taught me more about certificates as well as concepts and mechanisms I wasn't aware of before. Lots of approaches that are waiting to be explored further.
    • Certificates allow you to verify the identity of some entity, for example of a website. You trust certificates because some authority is satisfied enough to issue one, your browser trusts the authority enough to honor it, and you trust your browser to make good trust decisions. You can also trust that things, however, will go wrong. What if the site's private key is stolen? What if an authority mis-issues a certificate? What if an authority has its systems compromised?
    • Let's talk about remediation. There are certification revocation lists (CRL) you can check, yet it's hard to keep in sync with them. There is the Online Certificate Status Protocol (OCSP) where you can check just in time whether a certificate is still good, yet connection time causes latency. To work around this problem, there are methods like OCSP Stapling to bundle these requests, where Must-Staple is probably the best known way as of now.
    • What to do to prevent that things go wrong? HTTP public key pinning (HPKP) was used for quite some time but then phased out as it was open to abuse. Then there's the Certificate Authority Authorization (CAA), a DNS resource record mechanism which you can use to say that certificates for resources of a particular domain can only be provided by a particular certificate authority.
    • Finally, what about notification? Certificate Transparency (CT) is a cryptographically assured mechanism to allow clients to find out what certificates have been issued for a particular domain. Browsers can require certificate transparency. This way, after a certain date, all trusted certificates will be known.
  • "OWASP Top 10 2020" by Andrew van der Stock. An interesting look behind the scenes for one of the most commonly known OWASP projects!
    • If you haven't heard about the OWASP Top 10 yet, they are really worth a read. Although this document is sometimes mis-used as a standard, it's first and foremost meant for education purpose, as Andrew emphasized. It is a lightweight, developer-centric resource to raise awareness. An update was planned to be released in 2020, yet due to the current crisis situation we will have to wait for another year.
    • This talk allowed to have a look on how the top 10 are compiled. Andrew shared their difficulties to collaborate with organizations to obtain data, to perform data science and analysis, and also to get the desired industry attention and mindshare upon releasing a new version.
    • The group behind this project are collecting evidence from as many sources as they can. For the upcoming version they are aiming to improve their data science efforts as well as the community-driven qualitative process, having the community support the included risks. In addition, the project team is thinking about possibilities to allow anonymous data submissions. They also want to design a better look and feel, and offer more ways to consume the information to reach even more people.
    • What we can do to help is to donate data, help with the data analysis and data science part, respond to qualitative surveys, or peer review the content. If you can help, reach out to the project or any of their leaders.

The Training

Lots of different trainings got offered, yet in the end I opted for guided hands-on practice and picked the "Web Application Security Essentials" training by Fabio Cerullo. I cannot share the training content, yet I can share what it was based on - as I definitely recommend you to check it out for yourself.
  • The training focused on the first five of the current OWASP Top 10: injection, broken authentication, sensitive data exposure, XML external entities (XXE), and broken access control. We learned about the concepts behind as well as good practices to mitigate these risks.
  • To practice exploits and techniques hands-on, we used an application that was designed to teach them in lessons: OWASP WebGoat. The easiest way to have everything set up was to run the all-in-one WebGoat Docker image.
  • To help solve the exercises included in this application, we used the developer tools of FireFox or Chrome, as well as OWASP ZAP as a proxy. I got to know the FoxyProxy browser extension which helped easily switch proxy configurations.
For me personally, the training was great to observe myself and evaluate my current skills. For some techniques I understand the concept, yet I still need more practice to figure out a successful attack quicker. For some exploits, I still struggle to get my head around them. And then there are some challenges that feel way too easy and like everyday business. Things are relative, and practicing on my own in a guided manner made me realize once more: it's just a matter of practice. What I feel is easy, I've done a lot more often, even as part of usual "everyday" testing. The more tricky things are not more tricky themselves, I've just done them less and therefore it takes more time to get the syntax right or think of everything to consider.

I really like what Fabio emphasized at the end of the training. Security scanners are great tools that will check for certain rules, but they cannot help you to find flaws in your business logic. If you're serious about security testing you need highly skilled pen testers who also look at the business logic of your application. Testing is where imagination can take you. You see the response right away, notice a changed behavior in the application and see if you're on the right track. Proxies are useful to learn more about the application and get more information on potential issues, especially when developing or testing an API.

The Lessons

You may have noticed I didn't formulate a hypothesis for this experiment; I just jumped at the chance. Well, I decided to let it count as part of my #SecurityStories nonetheless. Yet if I would have had a hypothesis upfront, it would have probably looked like this.
I believe that attending the OWASP Virtual AppSec Days will result in new knowledge and inspiration.
I know I'll have succeeded when I learned about one new concept and had a new idea for another learning experiment in the area of information security.
Attending this conference was a great experience. It was tiring to do so three days in a row after work, yet I had the opportunity and don't regret I took it. Once more, I've learned more theory, I've got more tools in my tool belt, and I've practiced more. Inspiration for another learning experiment? Although I'm not yet sure whether I will pick it up or not, going through the other lessons of WebGoat would definitely be worth it.

Well, I can only hope you also learned something new in the area of information security from this post. If that's the case, then please leave a comment or drop me a direct message on Twitter. Let's continue learning!

No comments:

Post a Comment