BSides San Francisco - A Two-Day Community Celebration

San Francisco is home to many tech companies and cybersecurity experts, but for the last week of April, SF sees even more cybersecurity professionals from all over the world gather to share ideas and move the security conversation forward. While many people were getting in early for RSA, a special community event brought together speakers, workshop organizers, and volunteers running tech villages to explore and get hands-on experience. GitGuardian is proud to be a sponsor of this amazing event: BSidesSF!

The event started off with the keynote speaker encouraging us to "engage in joy in learning." If I and to narrow down the spirit of the whole event, it would be that we really did have a communal spirit of learning throughout all the sessions. Here are just a few of the highlights.

Understanding Emerging Cyber Threats

In her talk "The Expanding Universe of Cyber Threats," Dr. Xena Olsen walked us through a brief history of cyber threats, starting with the first virus, The Creeper. She then dug into what she sees as the emerging threats on the cybersecurity horizon. Along the way, she shared her favorite source for incident research: Verizon DBIR Data Breach Investigation Reports.

The first category of emerging threat Dr. Olson brought up was 'Information Operations.' Deep Fakes, Synthetics media, Disinformation, misinformation, and mal-information campaigns all fall under this threat. As artificial intelligence and deep fakes continue to improve, we need to keep our teams informed of ways to verify we are who we say we are and to be on the lookout for unusual, strange behavior.

The next threat she discussed was the continued rise of system intrusion. Finding and exploiting credentials or gaining access through misconfigurations is a growing issue. Even though these techniques are as old as the internet, they are far from being 'solved issues' and are actually getting worse over time. The GitGuardian State of Secret Sprawl report provides evidence to back this up.

She also enumerated the growing threats of fraud, including Business Email Compromises, BEC, and procurement scams. She also talked about the rise in supply chain and third-party component compromises that are driving so much of the conversation around SBOMs and VEX.

She said the motives behind cyber threats fall into five basic categories:

1. Disrupt - Opponents who want to hurt the productivity of an entity, causing a loss.
2. Destroy - Hate groups that want to completely remove another group from the internet fall into this category.
3. The Lulz - These are attackers just proving they can do a thing for bragging rights. Still very disruptive, but that is a side effect for the most part to the hackers in this category.
4. Espianoge - State-sponsored hacking gangs get paid a lot to exfiltrate government secrets. There is also ideology at play here, taking on enemy states.
5. Profit - This might be the largest category. While it can overlap with the other categories as well, in most breaches we have seen over the last few years, money was the significant motivator. Attackers typically go after credentials that can get them to machine resources to run crypto mining operations or data they can sell or ransom.

Helping Your Development Teams Embrace Security

There were multiple sessions that dove into how we can help our teams stay safe while also being seen as enablers, not just obstacles to the development process.

Grade The Repo, Not The Person

In his talk "Gamify security best practices to scalably improve engineering culture," David Trejo from Chime stated that we hire the best engineers at our companies because they are efficient and can make code do all sorts of amazing things. However, engineers don’t always know how to make code secure. When security teams approach development teams about better security posture, devs often get defensive,  pushing back as any criticism is easy to take as a personal attack and judgmental. Worse yet, our organizational leaders are left with low visibility into how we are protecting our environments and products, learning about your security lapses and breaches far more often than any positive security changes.

At Chime, they got tired of that cycle and built a tool called Monocle, which they plan to release as open source software in the near future. It is based on the idea of moving the feedback away from the developer and onto the repositories themselves. Monocle gives a badge to each repo in the README file, which grades the overall code on a scale from A (the best) to F (the worst). It also shows how it got to that grade and specific, actionable steps the dev team can take to raise the grade.

Aside from moving the 'blame' to the code, which helps with morale, Monocle also makes it far easier to audit their repos. So far, they calculate they saved over 2000 hours over doing manual audits. Leadership loves it, too, as they get a quick snapshot in real time of the overall grades and the trends throughout the org.

The other large advantage of this approach is that, since Monocle is a centrally managed tool, they can add new initiatives and specific, actionable steps to all the repos at once, making it very quick to adapt globally without needing to manually update individual devs. David said one of the goals was to move away from managing security through spreadsheets.

Finally, they use the tooling to celebrate when a grade gets raised on any repo. This change in approach now has developers embracing security updates faster as teams compete in a healthy way to raise their grades and be seen as leaders, versus fighting back on every change security suggested.

Translating Security Via Good Storytelling

Breanne Boland, Product Security Engineer from Gusto, believes in good storytelling as a tool to affect change. This was very evident in her very cleverly designed slides for her talk "New Apps, Good Snacks: Effective Threat Modeling for New Territory"

She encourages us to think of our role as security in the org as one of advising, not dictating. We are always discovering new threats, and we might be tempted to try and lay down the law to protect our organizations. However, we can be far more effective by taking the time to effectively explain the threats in terms the user and the developer can understand.

For example, developers might design a system that lets people stay logged in, even after inactivity, as they might assume the users are going to be responsible and always log out. While at the same time, users might not be used to logging out when done with the app. Asking for auto logout is an actionable approach rather than just informing devs of the issue. Overall making sure both the devs and the users know that auto logout is the better option can help each make better decisions.

Breanne also talked about privacy and data retention. She said if a data field is optional, don't ask for it. We need to encourage a culture of seeing how little data we can collect for each feature. Similarly, always asking for location sharing when it is not needed is a bad default position. Asking the user to "opt-in" is different than demanding they enable sharing in a popup without explaining the reason.

She stressed you, as a security professional, must meet the developers where they are. This means showing up to development meetings where you are allowed. It also means offering actionable feedback as well as background reading materials. While most devs will skip a 90-page PDF, having the resource will build trust in you as a security researcher.

She ended her session by reminding us all to think creatively as we are explaining new threats and to always push against complacency. The more complex the idea, the more effort you should put into reducing the delivery to simple key terms and actionable feedback. guidelines, reducing unneeded noise as much as possible. If done right, security can be seen as encouraging and enabling more ambitious tech work rather than being seen as an obstacle to it.

Proactive Security Means Education And Carrots Over Sticks

Dealing with security is extremely important at Chime, a financial app. However, as a startup, development speed can sometimes run against what the security team wants. Taking an antagonistic approach between teams will lead to everyone being unhappy, especially the customer. Arkadiy Tetelman and Mukund Sarma from Chime explain how they are working to keep everyone on the same team and working harmoniously in their sessions "What Does it Mean to Build a Proactive Security Culture in an Organization."

They started out by saying that "If people don't like you, you are not going to accomplish your goals." While the goal of your job is not just to be liked, taking on a partnership mentality and showing you are working in the developer's best interest can build a working relationship that makes it far easier to get the results we all want.

They stressed it is very important to meet with engineers early and often in the process. If you are involved in the code review and testing phases only, you are likely to be seen as someone to work around or against. If you are in the process from the design phase, laying out specifics of what you will be testing for before the code is even written, then you are likely going to be seen as a helpful partner, especially when all the code passes the tests days, or months, down the line.

They also encouraged opening up a channel of communication where devs can ask any and all security questions. Encouraging and celebrating devs taking a security-first approach is going to yield overall better results over calling out or trying to blame someone for failing at app security.

They said lunch and learns, with real practical examples, is another good way to bring teams together in low-pressure ways. The more tools that the security team can offer up, such as linting tools or git hooks scripts, can help devs do the right thing without making them do the lifting to find their own resources.

They detailed the power of empathy in communication. While we must be realistic about our goals and our expectations, we must also stay relevant to the real-world struggles engineers face. We must stay kind and never turn mean; otherwise, we are just going to end in a fight. One easy way to stay positive is to figure out what motivates individuals on the team and gear rewards toward their preferences. Celebrate all the wins and make sure leadership knows when things go right.

Keeping Customer Account Recovery Safe

As more and more people work online, the more likely it is that account takeover attempts will continue to increase, says Kelley Robinson from Twilio/Authy in her talk "Designing consumer account recovery in a 2FA world." While it is a good thing that the use of multifactor authentication, MFA, is on the rise, this also makes account recovery more of a challenge.

She stated, "Life happens, and people get locked out of accounts fairly often." Unlike with classic password resets, which typically just require email access to accomplish, full account recovery means re-proving who you are. This typically will require you to have specific knowledge, possess a specific device, and, increasingly, leverage social proof of who you are.

Account Recovery Factors

Specific knowledge generally means something specific to you that you would know and never forget but which might be hard to find via public information. For example, the color of your first bike as a child or where you went on your first date with your partner. Stay away from questions like where you went to high school or any other data that might be easy to glean from your social media profiles.

Possession means having a separate physical device that can generate or receive recovery codes. This might be your mobile device, but it could also be applications like Google Authenticator or Apple's Passkeys. Yubikey or other physical USB token devices are also encouraged. Backup codes are yet another possession path. Some companies report that 1% of users reset their accounts using backup codes regularly, so we should encourage people to store these safely.

Social proof is the newest method on her list. More and more social media companies are allowing you to specify specific connections to verify you are really you during recovery. This takes a certain amount of real-world trust and some common sense who is allowed to speak for you.

While there is a real need for setting up the path to recovery and these proof factors early in the account creation process, the reality is that from a sales and marketing perspective, anything that slows down customer signup is viewed as less than ideal. More hurdles to signing up for a service means high abandonment and lower overall conversion rates, which nobody wants. We are at a point where we need to find a balance between security and business goals.

She wrapped up her session with some simple do's and don'ts:
Do:

• Require users to register with additional proof factors.
• Remind users about recovery options often; GitHub does a great job at this asking you to reconfirm your backup strategy from time to time.
• Remind users about 2FA around the time people change phones. An annual email around the holidays is a good practice, as many people get upgraded phones as gifts.
• Force users to complete one successful 2FA enforce enabling 2FA.
• Add waiting periods for sensitive recovery. If they fail too many times, that can be a sign of a malicious attack.

Dont:

• Use one-factor authentication; use at least 2 factors, something you possess and something you know.
• Don't deactivate 2FA on account recovery. This might be an easier path for the customer but defeats the purpose of MFA.
• Don't give up on 2FA. There are still challenges, but overall the improved security is worth it.

She also cited the OWASP MFA cheat sheet as a good resource to share with your internal teams when having this discussion. While there is not 'only one best way' to deal with MFA, these tips can help your org better embrace secure account recovery.

A Very Special Community Event

I just touched on a few of the sessions in this article. There were also villages that saw students and people just getting into the field gain valuable hands-on experience in security hacking. There were, of course, the lockpicking and badge-hacking villages, but there was also a bug bounty village led by legendary hacker Jason Haddix, CISO and Hacker in Charge at BuddoBot these days. GitGuardian is proud we were able to sponsor this year's villages, including the career village, where folks just starting out could get hands-on help with their resumes.

After two amazing days and one excellent official after-party, we had to bring BSidesSF 2023 to a close. For a lot of people, the community spirit carried on as RSA began the next day, but that is the story for another article. I can not wait until next year's BSidesSF, it was truly an unforgettable community experience.