,

#ShareTheMicInCyber: Brooke Pearson

Posted by Parisa Tabriz, Head of Chrome Product, Engineering and UX 

In an effort to showcase the breadth and depth of Black+ contributions to security and privacy fields, we’ve launched a profile series that aims to elevate and celebrate the Black+ voices in security and privacy we have here at Google.

Brooke Pearson manages the Privacy Sandbox program at Google, and her team’s mission is to, “Create a thriving web ecosystem that is respectful of users and private by default.” Brooke lives this mission and it is what makes her an invaluable asset to the Chrome team and Google. 
In addition to her work advancing the fields of security and privacy, she is a fierce advocate for women in the workplace and for elevating the voices of her fellow Black+ practitioners in security and privacy. She has participated and supported the #ShareTheMicInCyber campaign since its inception.

Brooke is passionate about delivering privacy solutions that work and making browsing the web an inherently more private experience for users around the world.

Why do you work in security or privacy?

I work in security and privacy to protect people and their personal information. It’s that simple. Security and privacy are two issues that are core to shaping the future of technology and how we interact with each other over the Internet. The challenges are immense, and yet the ability to impact positive change is what drew me to the field.

Tell us a little bit about your career journey to Google

My career journey into privacy does not involve traditional educational training in the field. In fact, my background is in public policy and communications, but when I transitioned to the technology industry, I realized that the most pressing policy issues for companies like Google surround the nascent field of privacy and the growing field of security.

After I graduated from college at Azusa Pacific University, I was the recipient of a Fulbright scholarship to Macau, where I spent one year studying Chinese and teaching English. I then moved to Washington D.C. where I initially worked for the State Department while finishing my graduate degree in International Public Policy at George Washington University. I had an amazing experience in that role and it afforded me some incredible networking opportunities and the chance to travel the world, as I worked in Afghanistan and Central Asia.

After about five years in the public sector, I joined Facebook as a Program Manager for the Global Public Policy team, initially focused on social good programs like Safety Check and Charitable Giving. Over time, I could see that the security team at Facebook was focused on fighting the proliferation of misinformation, and this called to me as an area where I could put my expertise in communication and geopolitical policy to work. So I switched teams and I’ve been in the security and privacy field ever since, eventually for Uber and now with Google’s Chrome team.

At Google, privacy and security are at the heart of everything we do. Chrome is tackling some of the world’s biggest security and privacy problems, and everyday my work impacts billions of people around the world. Most days, that’s pretty daunting, but every day it’s humbling and inspiring.

What is your security or privacy “soapbox”?

If we want to encourage people to engage in more secure behavior, we have to make it easy to understand and easy to act on. Every day we strive to make our users safer with Google by implementing security and privacy controls that are effective and easy for our users to use and understand.

As a program manager, I’ve learned that it is almost always more effective to offer a carrot than a stick, when it comes to security and privacy hygiene. I encourage all of our users to visit our Safety Center to learn all the ways Google helps you stay safe online, every day.

If you are interested in following Brooke’s work here at Google and beyond, please follow her on Twitter @brookelenet. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.

If you are interested in participating or learning more about #ShareTheMicInCyber, click here.

/by

Sex in the digital era: How secure are smart sex toys?

ESET researchers investigate what could possibly go wrong when you connect your bedroom to the internet of things

The post Sex in the digital era: How secure are smart sex toys? appeared first on WeLiveSecurity

/by
,

Fuzzing Java in OSS-Fuzz

Posted by Jonathan Metzman, Google Open Source Security Team

OSS-Fuzz, Google’s open source fuzzing service, now supports fuzzing applications written in Java and other Java Virtual Machine (JVM) based languages (e.g. Kotlin, Scala, etc.). Open source projects written in JVM based languages can add their project to OSS-Fuzz by following our documentation.

The Google Open Source Security team partnered with Code Intelligence to integrate their Jazzer fuzzer with OSS-Fuzz. Thanks to their integration, open source projects written in JVM-based languages can now use OSS-Fuzz for continuous fuzzing.

OSS-Fuzz has found more than 25,000 bugs in open source projects using fuzzing. We look forward to seeing how this technique can help secure and improve code written in JVM-based languages.

What can Jazzer do?

Jazzer allows users to fuzz code written in JVM-based languages with libFuzzer, as they already can for code written in C/C++. It does this by providing code coverage feedback from JVM bytecode to libFuzzer. Jazzer already supports important libFuzzer features such as:

  • FuzzedDataProvider for fuzzing code that doesn’t accept an array of bytes.
  • Evaluation of code coverage based on 8-bit edge counters.
  • Value profile.
  • Minimization of crashing inputs.

The intent for Jazzer is to support all libFuzzer features eventually.

What Does Jazzer Support?

Jazzer supports all languages that compile to JVM bytecode, since instrumentation is done on the bytecode level. This includes:

  • Java
  • Kotlin
  • Scala
  • Clojure

Jazzer can also provide coverage feedback from native code that is executed through JNI. This can uncover interesting memory corruption vulnerabilities in memory unsafe native code.

Why Fuzz Java/JVM-based Code?

As discussed in our post on Atheris, fuzzing code written in memory safe languages, such as JVM-based languages, is useful for finding bugs where code behaves incorrectly or crashes. Incorrect behavior can be just as dangerous as memory corruption. For example, Jazzer was used to find CVE-2021-23899 in json-sanitizer which could be exploited for cross-site scripting (XSS). Bugs causing crashes or incorrect exceptions can sometimes be used for denial of service. For example, OSS-Fuzz recently found a denial of service issue that could have been used to take “a major part of the ethereum network offline”.

When fuzzing memory safe code, you can use the same classic approach for fuzzing memory unsafe code: passing mutated input to code and waiting for crashes. Or you can take a more unit test like approach where your fuzzer verifies that the code is behaving correctly (example).

Another way fuzzing can find interesting bugs in JVM-based code is through differential fuzzing. With differential fuzzing, your fuzzer passes mutated input from the fuzzer to multiple library implementations that should have the same functionality. Then it compares the results from each library to find differences.
Check out our documentation to get started. We will explore this more during our OSS-Fuzz talk at FuzzCon Europe.

/by

Exchange servers under siege from at least 10 APT groups

ESET Research has found LuckyMouse, Tick, Winnti Group, and Calypso, among others, are likely using the recent Microsoft Exchange vulnerabilities to compromise email servers all around the world

The post Exchange servers under siege from at least 10 APT groups appeared first on WeLiveSecurity

/by

Online health security – when ‘opt out’ isn’t an option

What happens when you try to opt out of e-health to avoid issues in the event of a breach?

The post Online health security – when ‘opt out’ isn’t an option appeared first on WeLiveSecurity

/by
,

Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity

Posted by Kim Lewandowski & Dan Lorenc, Google Open Source Security Team

One of the fundamental security issues with open source is that it’s difficult to know where the software comes from or how it was built, making it susceptible to supply chain attacks. A few recent examples of this include dependency confusion attack and malicious RubyGems package to steal cryptocurrency.

Today we welcome the announcement of sigstore, a new project in the Linux Foundation that aims to solve this issue by improving software supply chain integrity and verification.

Installing most open source software today is equivalent to picking up a random thumb-drive off the sidewalk and plugging it into your machine. To address this we need to make it possible to verify the provenance of all software – including open source packages. We talked about the importance of this in our recent Know, Prevent, Fix post.

The mission of sigstore is to make it easy for developers to sign releases and for users to verify them. You can think of it like Let’s Encrypt for Code Signing. Just like how Let’s Encrypt provides free certificates and automation tooling for HTTPS, sigstore provides free certificates and tooling to automate and verify signatures of source code. Sigstore also has the added benefit of being backed by transparency logs, which means that all the certificates and attestations are globally visible, discoverable and auditable.

Sigstore is designed with open source maintainers, for open source maintainers. We understand long-term key management is hard, so we’ve taken a unique approach of issuing short-lived certificates based on OpenID Connect grants. Sigstore also stores all activity in Transparency Logs, backed by Trillian so that we can more easily detect compromises and recover from them when they do occur. Key distribution is notoriously difficult, so we’ve designed away the need for them by building a special Root CA just for code signing, which will be made available for free.

We have a working prototype and proof of concepts that we’re excited to share for feedback. Our goal is to make it seamless and easy to sign and verify code:

It has been fun collaborating with the folks from Red Hat and the open source community on this project. Luke Hinds, one of the lead developers on sigstore and Security Engineering Lead at Red Hat says, “I am very excited about sigstore and what this means for improving the security of software supply chains. sigstore is an excellent example of an open source community coming together to collaborate and develop a solution to ease the adoption of software signing in a transparent manner.” We couldn’t agree more.

Mike Malone, the CEO of Smallstep, helped with the overall design of sigstore. He adds, “In less than a generation, open source has grown from a niche community to a critical ecosystem that powers our global economy and institutions of society and culture. We must ensure the security of this ecosystem without undermining the open, decentralized collaboration that makes it work. By building on a clever composition of existing technologies that respect privacy and work at scale, sigstore is the core infrastructure we need to solve this fundamental problem. It’s an ambitious project with potential for global impact. I’m impressed by the rapid progress that’s been made by Google, Red Hat, and Linux Foundation over the past few months, and I’m excited to hear feedback from the broader community.”

While we are happy with the progress that has been made, we know there is still work to be done before this can be widely relied upon. Upcoming plans for sigstore include: hardening the system, adding support for other OpenID Connect providers, updating documentation and responding to community feedback.

Sigstore is in its early days, but we’re really excited about its future. Now is a great time to provide feedback, try out the tooling and get involved with the project as design details are still being refined.

/by

WhatsApp may soon roll out encrypted chat backups

While chats are end-to-end encrypted, their backups are not – this may change soon

The post WhatsApp may soon roll out encrypted chat backups appeared first on WeLiveSecurity

/by

Women in cybersecurity: Gender gap narrows but not enough

The number of women joining the ranks of cybersecurity practitioners is steadily increasing, but a lot still needs to be done to close the gap

The post Women in cybersecurity: Gender gap narrows but not enough appeared first on WeLiveSecurity

/by

Going dark: Service disruptions at stock exchanges and brokerages

Are you a bull or a bear? If you can’t access your data and money, do your sentiments about the market still matter?

The post Going dark: Service disruptions at stock exchanges and brokerages appeared first on WeLiveSecurity

/by

Week in security with Tony Anscombe

Four zero-days patched in Microsoft Exchange Server – A tale about an unsophisticated criminal – Web trackers in a password manager app

The post Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by