20 tips for 2020: Mistakes to avoid

In this first instalment of the two-article series we will be looking at cybersecurity habits to avoid when using your computing devices

The post 20 tips for 2020: Mistakes to avoid appeared first on WeLiveSecurity

/by

Prison surveillance footage posted on YouTube

It’s not a stretch to surmise that the incident was enabled by poor security settings

The post Prison surveillance footage posted on YouTube appeared first on WeLiveSecurity

/by

How to get rid of your old devices safely

Disposing of old tech isn’t a one-click solution; there are multiple things you have to consider before moving on to greener pastures

The post How to get rid of your old devices safely appeared first on WeLiveSecurity

/by

How to secure your digital Christmas presents

What are some of the key things you should do with your shiny new device as soon as you unbox it?

The post How to secure your digital Christmas presents appeared first on WeLiveSecurity

/by

Week in security with Tony Anscombe

ESET’s free BlueKeep vulnerability checker – Dangerous PayPal-themed scam – This year’s worst passwords

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

/by

Ambitious scam wants far more than just PayPal logins

An ongoing phishing scam uncovered by ESET researchers seeks to wreak havoc on your money and digital life in one fell swoop

The post Ambitious scam wants far more than just PayPal logins appeared first on WeLiveSecurity

/by

38,000 people forced to pick up email passwords in person

Malware and legal requirements force academics and students to join a near-endless line in order to pick up their passwords

The post 38,000 people forced to pick up email passwords in person appeared first on WeLiveSecurity

/by

Announcing updates to our Patch Rewards program in 2020

Posted by Jan Keller, Technical Program Manager, Security 

At Google, we strive to make the internet safer and that includes recognizing and rewarding security improvements that are vital to the health of the entire web. In 2020, we are building on this commitment by launching a new iteration of our Patch Rewards program for third-party open source projects.

Over the last six years, we have rewarded open source projects for security improvements after they have been implemented. While this has led to overall improved security, we want to take this one step further.

Introducing upfront financial help
Starting on January 1, 2020, we’re not only going to reward proactive security improvements after the work is completed, but we will also complement the program with upfront financial support to provide an additional resource for open source developers to prioritize security work. For example, if you are a small open source project and you want to improve security, but don’t have the necessary resources, this new reward can help you acquire additional development capacity.

We will start off with two support levels :

  • Small ($5,000): Meant to motivate and reward a project for fixing a small number of security issues. Examples: improvements to privilege separation or sandboxing, cleanup of integer artimetrics, or more generally fixing vulnerabilities identified in open source software by bug bounty programs such as EU-FOSSA 2 (see ‘Qualifying submissions’ here for more examples).
  • Large ($30,000): Meant to incentivize a larger project to invest heavily in security, e.g. providing support to find additional developers, or implement a significant new security feature (e.g. new compiler mitigations).

Nomination process

Anyone can nominate an open source project for support by filling out http://goo.gle/patchz-nomination. Our Patch Reward Panel will review submissions on a monthly basis and select a number of projects that meet the program criteria. The panel will let submitors know if a project has been chosen and will start working with the project maintainers directly.

Projects in scope

Any open source project can be nominated for support. When selecting projects, the panel will put an emphasis on projects that either are vital to the health of the Internet or are end-user projects with a large user base.

What do we expect in return?

We expect to see security improvements to open source software. Ideally, the project can provide us
with a short blurb or pointers to some of the completed work that was possible because of our support. We don’t want to add bureaucracy, but would like to measure the success of the program.
What about the existing Patch Rewards program?
This is an addition to the existing program, the current Patch Rewards program will continue as it stands today.

/by

Protecting programmatic access to user data with Binary Authorization for Borg

Posted by Daniel Rebolledo Samper and Mark Lodato, Software Engineers, Security & Privacy

At Google, the safety of user data is our paramount concern and we strive to protect it comprehensively. That includes protection from insider risk, which is the possible risk that employees could use their organizational knowledge or access to perform malicious acts. Insider risk also covers the scenario where an attacker has compromised the credentials of someone at Google to facilitate their attack. There are times when it’s necessary for our services and personnel to access user data as part of fulfilling our contractual obligations to you: as part of their role, such as user support; and programmatically, as part of a service. Today, we’re releasing a whitepaper, “Binary Authorization for Borg: how Google verifies code provenance and implements code identity,” that explains one of the mechanisms we use to protect user data from insider risks on Google’s cluster management system Borg.


Binary Authorization for Borg is a deploy-time enforcement check
Binary Authorization for Borg, or BAB, is an internal deploy-time enforcement check that reduces insider risk by ensuring that production software and configuration deployed at Google is properly reviewed and authorized, especially when that code has the ability to access user data. BAB ensures that code and configuration deployments meet certain standards prior to being deployed. BAB includes both a deploy-time enforcement service to prevent unauthorized jobs from starting, and an audit trail of the code and configuration used in BAB-enabled jobs.

BAB ensures that Google’s official software supply chain process is followed. First, a code change is reviewed and approved before being checked into Google’s central source code repository. Next, the code is verifiably built and packaged using Google’s central build system. This is done by creating the build in a secure sandbox and recording the package’s origin in metadata for verification purposes. Finally, the job is deployed to Borg, with a job-specific identity. BAB rejects any package that lacks proper metadata, that did not follow the proper supply chain process, or that otherwise does not match the identity’s predefined policy.


Binary Authorization for Borg allows for several kinds of security checks
BAB can be used for many kinds of deploy-time security checks. Some examples include:

  • Is the binary built from checked in code?
  • Is the binary built verifiably?
  • Is the binary built from tested code?
  • Is the binary built from code intended to be used in the deployment?

After deployment, a job is continuously verified for its lifetime, to check that jobs that were started (and any that may still be running) conform to updates to their policies.

Binary Authorization for Borg provides other security benefits
Though the primary purpose of BAB is to limit the ability of a potentially malicious insider to run an unauthorized job that could access user data, BAB has other security benefits. BAB provides robust code identity for jobs in Google’s infrastructure, tying a job’s identity to specific code, and ensuring that only the specified code can be used to exercise the job identity’s privileges. This allows for a transition from a job identity—trusting an identity and any of its privileged human users transitively—to a code identity—trusting a specific piece of reviewed code to have specific semantics and which cannot be modified without an approval process.

BAB also dictates a common language for data protection, so that multiple teams can understand and meet the same requirements. Certain processes, such as those for financial reporting, need to meet certain change management requirements for compliance purposes. Using BAB, these checks can be automated, saving time and increasing the scope of coverage.

Binary Authorization for Borg is part of the BeyondProd model
BAB is one of several technologies used at Google to mitigate insider risk, and one piece of how we secure containers and microservices in production. By using containerized systems and verifying their BAB requirements prior to deployment, our systems are easier to debug, more reliable, and have a clearer change management process. More details on how Google has adopted a cloud-native security model are available in another whitepaper we are releasing today, “BeyondProd: A new approach to cloud-native security.”
In summary, implementing BAB, a deploy-time enforcement check, as part of Google’s containerized infrastructure and continuous integration and deployment (CI/CD) process has enabled us to verify that the code and configuration we deploy meet certain standards for security. Adopting BAB has allowed Google to reduce insider risk, prevent possible attacks, and also support the uniformity of our production systems. For more information about BAB, read our whitepaper, “Binary Authorization for Borg: how Google verifies code provenance and implements code identity.”

Additional contributors to this whitepaper include Kevin Chen, Software Engineer; Tim Dierks, Engineering Director; Maya Kaczorowski, Product Manager; Gary O’Connor, Technical Writing; Umesh Shankar, Principal Engineer; Adam Stubblefield, Distinguished Engineer; and Wilfried Teiken, Software Engineer; with special recognition to the entire Binary Authorization for Borg team for their ideation, engineering, and leadership

/by

It’s time to disconnect RDP from the internet

Brute-force attacks and BlueKeep exploits usurp convenience of direct RDP connections; ESET releases a tool to test your Windows machines for vulnerable versions

The post It’s time to disconnect RDP from the internet appeared first on WeLiveSecurity

/by