Yes, you read that right! My friends at Bright bought my company, We Hack Purple! Bright makes a DAST (dynamic application security testing tool), and I have been on their advisory board for some time, so we know each other well and have been working together for years. They also just released a brand new tool for the Lucky Framework (crystal programming language), which creates security-focused unit tests, automagically! Trust me, it’s very cool, and there’s more on the way!
As part of this deal, starting immediately, all of the courses from the We Hack Purple Academy will be available in the We Hack Purple Community, for FREE. Yes, you heard that right. Secure coding for everyone!
So what comes next? I plan to work with Bright for the next couple years, creating more content, running the We Hack Purple Community, speaking at conferences and helping to improve the Bright products until they are absolutely spectacular. I will also start on writing my next book, Alice and Bob Learn Secure Coding.
I haven’t written in my personal blog in a while, and I have good reasons (I moved to a new city, the new place will be a farm, I restarted my international travel, something secret that I can’t announce yet, and also did I mention I was a bit busy?). But I still can’t get over log4j (see previous article 1, article 2, and the parody song). The sheer volume of work involved (one company estimated 100 weeks of work, completed over the course of 8 days of time) in the response was spectacular, and the damage caused is still unknown at this point. We will likely never know the true extend of the cost of this vulnerability. And this bugs me.
I met up last month with a bunch of CISOs and incident responders, to discuss the havoc that was this zero-day threat. What follows are stories, tales, facts and fictions, as well as some of my own observations. I know it’s not the perfect story telling experience you are used to here, bear with me, please.
Short rehash: log4j is a popular java library used for application logging. A vulnerability was discovered in it that allowed any user to paste a short string of characters into the address bar, and if vulnerable, the user would have remote code execution (RCE). No authentication to the system was required, making this the simplest attack of all time to gain the highest possible level of privilege on the victim’s system. In summary: very, very scary.
Most companies had no reason to believe they had been breached, yet they pulled together their entire security team and various other parts of their org to fight against this threat, together. I saw and heard about a lot of teamwork. Many people I spoke to told me they had their security budgets increased my multitudes, being able to hire several extra people and buy new tools. I was told “Never let a good disaster go to waste”, interesting….
I read several articles from various vendors claiming that they could have prevented log4j from happening in the first place, and for some of them it was true, though for many it was just marketing falsehoods. I find it disappointing that any org would publish an outright lie about the ability of their product, but unfortunately this is still common practice for some companies in our industry.
I happened to be on the front line at the time, doing a 3-month full time stint (while still running We Hack Purple). I had *just* deployed an SCA tool that confirmed for me that we were okay. Then I found another repo. And another. And another. In the end they were still safe, but finding out there had been 5 repos full of code, that I was unaware of as their AppSec Lead, made me more than a little uncomfortable, even if it was only my 4th week on the job.
I spoke to more than one individual who told me they didn’t have log4j vulnerabilities because the version they were using was SO OLD they had been spared, and still others who said none of their apps did any logging at all, and thus were also spared. I don’t know about you, but I wouldn’t be bragging about that to anyone…
For the first time ever, I saw customers not only ask if vendors were vulnerable, but they asked “Which version of the patch did you apply?”, “What day did you patch?” and other very specific questions that I had never had to field before.
I heard several vendors have their customers demand “Why didn’t you warn us about this? Why can’t your xyz tool prevent this?” when in fact their tool has nothing to do with libraries, and therefore it’s not at all in the scope of the tool. This tells me that customers were quite frightened. I mean, I certainly was….
Several organizations had their incident response process TESTED for the first time. Many of us realized there were improvements to make, especially when it comes to giving updates on the status of the event. Many people learned to improve their patching process. Or at least I hope they did.
Those that had WAF, RASP, or CNDs were able to throw up some fancy REGEX and block most requests. Not a perfect or elegant solution, but it saved quite a few company’s bacon and reduced the risk greatly.
I’ve harped on many clients and students before that if you can’t do quick updates to your apps, that it is a vulnerability in itself. Log4j proved this, as never before. I’m not generally an “I told you so” type of person. But I do want to tell every org “Please prioritize your ability to patch and upgrade frameworks quickly, this is ALWAYS important and valuable as a security activity. It is a worthy investment of your time.”
Again, I apologize for this blog post being a bit disjointed. I wasn’t sure how to string so many different thoughts and facts into the same article. I hope this was helpful.
All of the streams are free, and I would love to have you join us live! If you can’t make it live, you can watch them after on my YouTube Channel, or download them via a podcast app by looking for the podcast “Alice and Bob Learn” (which will be launched right after the first stream).
Ideally, you will read the chapter before the corresponding live discussion, but if you don’t, that’s okay. You will still learn, and you are definitely will welcome to attend. 😀
I joined the NeuraLegion Advisory Board because they’re really fun to work with. Gosh, that would make for a short blog post, wouldn’t it?
When I started my quickly failed startup in 2019, Security Sidekick, Bar Hofesh reached out to me to see if he and Gadi Bashvitz could help. I was pleasantly surprised to have several people in my industry reach out to me, and even other small companies reaching out to see how they could help me with my startup. InfoSec is full of kind and generous people, let me tell you.
When I left Microsoft, I had committed to several speaking engagements before I decided to leave, including the 2020 RSA conference, and rather than be in breach of contract with several conferences and potentially ruin my reputation, I completed all of the obligations that I had made while I worked there. But there was a catch: I had to pay for all my travel myself. Bar and Gadi knew this, so they offered me a free place to stay (in San Francisco!!!!!) which I really appreciated. It didn’t work out in the end, but we met up in person for the first time for some Starbucks, and it was awesome.
You know that feeling when you meet someone, and you like them immediately? Bar and I talked nerdy, and Gadi tolerated us. We continued to stay in touch.
Fast forward a few more months and the NeuraLegion tool NexDast was fully developed, and I had started We Hack Purple. We decided we wanted to find an excuse to work together, because we got along so well, and we all feel really passionately about security and changing our industry for the better.
We decided that we would plan a workshop together; I would teach a bunch of cool DevSecOps stuff, we would use Broken Crystals (more on this in another blog post), and demo their product. We made a GitHub action together, we made a workshop together, and of course we found lots of bugs together. It was super, duper fun and a smashing success!
Then Christmas and Hanukkah came, and Gadi called me up. He asked me if I wanted to join their Advisory Board, so we no longer had to make excuses to work together. What could I say? I said yes.
We have so many ideas of fun and awesome things we are going to work on together, to make their product even better, and to give back to the community. In addition to being great people, we also share a commitment to shifting security left and making sure application security is liberated and automated as part of the SDLC, and put in the hands of developers, not just AppSec people.
I’m honored to be on their Advisory Board, and I feel lucky to have the chance to work with such a talented and fun team.
You can actually play online, for free! It just came online last week. Play online here.
She also mentions that you should play Backdoors and Breaches, however, that is an incident response card game. You should still play it, but it won’t teach you threat modelling. 😀
Every time there is a new project at work, meet with them for one hour and just *try* to threat model. It’s okay if it’s not perfect, if you identify just one risk you had not thought of, your sessions was productive.
Every time someone else at work is doing a threat model, sit in and “job shadow” them. Learning by watching and participating is a fantastic way to get in the middle of things.