Category Archives: Google

Google Creates New Security Center for G-Suite Enterprise Customers

Google is trying to keep up with the Jones (AKA Micosoft) and is building some security tools for its enterprise customers.  Microsoft is way ahead in this area and if Google wants to compete in the enterprise space it needs to offer enterprise class tools.

First of all, this only is available to G-Suite Enterprise customers.  Most Google users use the free version.  Above that is Basic at $5 per user per month, then Business at $10 and finally Enterprise at $25.  So this capability is only available to a small percentage of Google customers.

Still, those customers are the ones with the best revenue per customer and Google is losing some of them back to Microsoft.

For enterprise customers, this is a great addition.

For some customers, this may be motivation to upgrade to the next level of pricing plan.

The first piece of the security center is a dashboard that gives admins a view of their overall security posture.  It gives those admins a view across products like GMail, Google Drive and others.

The second feature gives the admin an overview of the company’s cyber security settings and make recommendations for improving security.

Google’s plan is to continue to enhance the dashboard so that it will have more features and functionality.

This is a smart move on Google’s part.  Hopefully, they will give Business class users access to this.  It may be that they are testing it on enterprise customers to tune it or maybe they will create a stripped down version for Business customers.  Clearly, this is a useful tool.

If you are a Google Enterprise customer, you should check this out.


Information for this post came from Techcrunch.

Facebooktwitterredditlinkedinmailby feather

Don’t Turn on WiFi on Your Phone Until You Patch it

An interesting vulnerability was just announced that affects both Apple and Google/Android phones.  That is something that is very unusual.

The bug is tied to a part of all cell phones called the baseband processor.  It is the part of the phone that controls the radios inside your phone.  In this case, the chip is the Broadcom 43xx family of chips.  According to Broadcom this chip can control your cellular radio, WiFi, Bluetooth and FM radio all on one chip.

Unfortunately, researchers found a bug in the WiFi code that would allow an attacker to take over the baseband processor and from there, the entire phone.

The reason this affects both Apple and Android phones is that this chip is used by almost everyone.  From iPhone 5s to the newest Android phones, they are all impacted.

Apple just released iOS 10.3.3 (which may or may not have been downloaded to your iPhone yet) and Google just released an Android patch in the July updates.  Unlike Apple devices, Android users have to wait for manufacturers to pick up Google’s fixes and test them and then wait again for carriers to make them available.  The only users who do not have to wait are Google branded Android phone users.  Those users get their patches directly from Google.

What can you do?

Three answers.

If you are an Apple user, download iOS 10.3.3 and install it.  Done!

If you are a user who is running a relatively new version of the Android OS on your phone AND your phone manufacturer/carrier is actively releasing updates, you should install the July update as soon as it is available.  That might be 30 days or more.

If you are running an older version of the Android OS and/or your carrier/phone vendor is not releasing security updates, you are kind of out of luck.  Turn off your WiFi and DO NOT TURN IT ON EVER AGAIN.  This is probably. for most people, time to get a new phone.

Why, you say, am I so aggressive about this?

The report is that you only have to be within radio range of the WiFi access point which is trying to attack you in order to be compromised.  You DO NOT need to connect to that access point.  You do not need to open a web browser.  You do not need to install an app.  You do not need to click on a link.  All you need to do is be near a rogue WiFi access point – which could easily be hidden in someone’s backpack.

So, for now, until you have installed the patch, if you can, leave WiFi off.  If you can’t, then only turn it on when you have to.

We will know more after the researcher presents his findings at Blackhat later this month, but at least from what we have heard, this don’t not affect Windows or Mac computers, only mobile devices. But, stay tuned;  this is not the end of the story.

Information for this post came from Threatpost.

Facebooktwitterredditlinkedinmailby feather

Google Adds Easy iOS Management Option for G-Suite Users

For those Google G-Suite (AKA Google Apps and Google Apps for Work) users, Google has released a new option for managing iPhones and iPads.

What is great about it is that it does NOT require installing an agent on the phone or pad.

Google calls it the Basic Mobile Management option for iOS and it allows G-Suite administrators to manage iOS devices without having to install an agent or a profile.

It allows administrators to enforce screen locks or passwords on the devices including the minimum or maximum number of characters in a password and the expiration period.

It can also force a factory reset after too many failed login attempts.

Administrators can wipe the entire device if it is lost or stolen or just G-Suite data if the user is leaving the company.

The software allows an administrator to see all of the devices connected to their domain which is certainly a nice feature.

Administrators will be able to set up corporate accounts on the devices similarly to setting up personal accounts.

Google does offer a more robust product, advanced mobile management, for users that want even more features, but for a lot of companies. Basic will be sufficient.

Curiously, this only works on non-Google (Apple) devices.  Users have to install an agent on Android devices to do the same thing.

Google Mobile Management is available at no extra charge for G-Suite users.

Information for this post came from eWeek and Google Support and G-Suite admin help.


Facebooktwitterredditlinkedinmailby feather

The End of the Road for HTTP://

Google has decided to lead the way on web, as it often has.  In this case, Google has announced that as of January 1, 2017, web pages that transmit credit cards or ask for passwords over HTTP (vs. HTTPS) will be marked with this flag in the address bar:


Some of will say that this is as it should be, and I will be the first to agree with you. Any web site that asks for your userid and password over an unsecure connection needs to be flogged appropriately.  Likewise if a web site asks for credit card information in clear text, it is, at the very minimum, in violation of the merchant agreement that the company signed with its bank.  It too needs to mend its ways.

My guess is that there are way too many sites that will get scooped up in this NOT SECURE net come January 1.  It likely will be like the changeover to chip based credit cards.  When last September came, people said “crap” – or some to that effect – they aren’t kidding;  they really are going to leave this deadline in place and companies started doing what they should have been doing a year prior to that. However, they discovered that fixing this problem was harder than they thought.  As a result, almost a year past this deadline, there are still hundreds of thousands of businesses that have not converted.  I do predict that almost every single major site will have this handled well in advance.  No doubt Google is already talking to major web properties privately.

In this case, people may think that Google will blink.  While no one knows for sure, I would not bet on that outcome.

But this is not where it ends.  It ends with, in Google’s view, the death of HTTP.

The next step is to label all pages that are loaded without encryption when the user is in incognito mode as NOT SECURE.

Finally, the last step is to label all pages loaded with HTTP as NOT SECURE.  They have not provided a date for this, but it may well be during 2017.

Of course, this only affects users who use a Google browser on their computer or phone, but according to W3Schools, this is over 72% right now – and growing.  Last August, that percentage was only 64% (see stats here).

Since most businesses do not want their customers to see that message when going to their web site, they will finally, reluctantly, migrate all traffic to HTTPS.

And to be clear, this does not mean optionally HTTPS;  this means mandatory HTTPS.

The biggest challenge will be for companies that have hundreds or thousands of web sites.  They will need to touch each one of them.  They may need to order an SSL certificate for each one.  It will require some work.

My recommendation is to start now and avoid the New Year’s Eve rush.


Information for this post came from Google’s security blog.



Facebooktwitterredditlinkedinmailby feather

Google Fixes Over 100 Bugs In Android


It appears that Google is getting serious about Android security.  They have, for the past several months, been releasing patch updates every month – like other software companies.  While I have no visibility to AT&T and Verizon, Sprint has been religious at pushing those updates out to my phone.

This month they released patches covering over 100 bugs in both the Android core OS and in chipset drivers from various component chip manufacturers.

Phone vendors have a choice between two different update packages to distribute to their customers.

Android’s Mediaserver component is the recipient of 16 patches, including 7 rated as critical.  These bugs, like Stagefright before it, allow hackers to attack your phone just by sending it specially crafted text (MMS) messages or audio and video files.  This works because the Android OS, in an effort to speed things up when a user wants to open a picture, audio or video file, pre-processes those files in the background without asking or telling you.  If those files are infected, so is your phone.  It has been so bad that Google Hangouts, for example, no longer  pass media files to this component automatically.

Another critical vulnerability is in the built in crypto libraries, OpenSSL and BoringSSL.

The first of the two patch options, labelled 2016-07-01 when you go to SETTINGS|ABOUT in Marshmallow, fixes 32 bugs, 8 of which are critical, 15 high and 9 moderate.  These bugs apply to the core Android OS.  32 bugs starts to rival Microsoft patches, but doesn’t reach the level of Adobe Flash patches.

The other patch option, labelled 2016-07-05 in ABOUT fixes 75 additional bugs that are device specific, meaning some may affect this device while others may effect a different device.

These fixes are in modules such as the Qualcomm GPU driver, the MediaTek WiFi driver, the Qualcomm performance component, the NVIDIA video driver, the kernel file system (not sure why this is device specific though), the USB driver and other unspecified drivers.

Since these are running in a privileged process, a compromise of these modules is a serious problem.  In fact, some of these compromises may only be repairable by reflashing the device firmware, something most users cannot do even if they wanted to.

There are an additional 54 high severity bugs in various drivers that can also lead to a complete device compromise. The difference here is that an attacker would have had to already compromise the phone in order to exploit these 54 bugs.

Google has already released these patches to Google branded Nexus phones – possibly the most important reason to buy a Nexus phone.  How long it will take the various phone manufacturers to get off their collective butts and release them is unknown.

In the meantime, hackers around the world have access to these patches and are busy reverse engineering them to figure out how to attack your phone – it is a race to the bottom.

While this is the biggest Android patch release I have ever seen Google release in a single month, I think, maybe, it is a good thing.  I am hoping that it means that Google is getting serious about upgrading the security of Android and not just trying to cram as many features as possible into the next release.

What this does mean is that users who are running Lollipop (Android 5), Jelly Bean (Android 4.1), Ice Cream Sandwich (Android 4.0) and earlier are at significant risk of compromise because these versions of the Android OS will never be patched.

As of June 1st, 2016, only 10 percent of Android phones were running Marshmallow.  Apple is quite a bit better in FORCING adoption of new versions of the OS because they own the OS and the phone, but this may change as Congress is looking at passing a law forcing phone vendors to patch phones that they sell.  If you make money from it, you have to patch it.  Since Google isn’t releasing patches for older versions, this will force the phone makers, if the law is enacted, to upgrade the phones to the current version.  From a user standpoint, this would be a good thing.

As a consumer, if you are concerned about the security of your data, or, if you are a business and you are concerned about the security of your company systems accessed by employee phones, you need to consider replacing phones on a regular basis.  If you combine Android 5 and 6 together, this still represents less than half the Android phones.  Many of the phones running Android 4 and earlier are likely outside the U.S., but companies, especially, need to be proactive about dealing with this.

Information for this post came from Infoworld.

Facebooktwitterredditlinkedinmailby feather

Yet Another Major Open Source Program Flaw Discovered – After 8 Years

Some people are big advocates of open source because, they say, since people can look at the source, bugs are found more quickly.

I am not a big supporter of that theory even though I am a supporter of open source because just because people CAN look at the source, doesn’t mean that they will and just because they DO look at it, doesn’t mean they will find the bugs.

On a side note, OpenSSL, the super popular open source SSL software package used in many apps and on many web sites will be releasing patches on March 1st for multiple vulnerabilities.

Google announced this week another major open source software package vulnerability.  The package, GLibc, provides basic functionality for C Language software developers.  While not used by every C developer, it is an extremely popular library – likely used in tens of thousands  of applications.

Going back to the open source conversation, this bug was introduced in 2008 – 8 years ago.  And, it was only discovered by accident when a Google developer kept crashing his system.  After some work, the Google team discovered that it was caused by a bug in Glibc.

And the bug is pretty serious.  It allows a hacker to intercept a DNS request and respond with a specially crafted response which allows the attacker to take over the computer by inserting an arbitrary program up to 64,000 bytes and then running it.

The problem with these two bugs – and the fact that they are open source doesn’t really impact this issue – is that developers who use this package need to release an update and every single user needs to install that update.

In fact, these two open source packages are ATYPICAL because they both have teams that support them.  Many open source software packages don’t have formal support teams.

For major developers, such as many Linux distributions, there are likely patches already in the works and users will likely install them.

The problem comes with smaller software packages and dedicated hardware devices that use it – companies that may no longer be supporting that version of the software or hardware or even companies that have gone out of business.

Since Glibc is a large library, many Internet Of Things developers don’t use that library.   For us, that is a good thing.

But as an end user, we likely have no clue which software packages on our devices use the affected library.  Since the bug has been around for 8 years, any software product that uses the library, likely uses the infected version.


The OpenSSL announcement – minus details as is their standard policy  – can be found here.

Information on the Glibc bug can be found in Ars Technica, here.

Facebooktwitterredditlinkedinmailby feather