Archive | Uncategorized RSS feed for this section

The Fatal Flaw of the Apple Pencil

I’m not an artist.

I’m a highly mobile business user. I use my iPad Pro several hours a day, and absolutely love the Apple’s Smart Keyboard that goes along with it. It’s the primary way I interface with my tablet. Coupled with Office 365 and a handful of apps, I can pretty much do anything I need to do.

I also bought the $99 Apple Pencil because I’m a sucker for good marketing… and it is very handy to use. It’s especially useful with apps like PDF Expert so that I can mark up documents to provide feedback to my team. I only need to use the Pencil a couple of times a week though at most, and therein lies the problem.

When Apple created the Pencil, they designed it so it was always ready at a moments notice. I suspect if you’re an artist that uses it frequently throughout the day that’s a great thing. To facilitate that capability though, the Pencil holds an active Bluetooth connection open to the iPad, slowly draining the battery.

Since I carry it around in my backpack with my iPad, it holds that connection open and is generally dead and when I grab it. It takes less than a minute to get a very usable charge (kudos to Apple for that), but it interrupts my workflow so much that I’ve gotten in the habit of not using it.

The only way to prevent that from happening, is by either unpairing the Pencil or turning off Bluetooth. Both actions sever the connection and put the Pencil to sleep. Neither of those are solutions though, they’re workarounds, and I don’t believe in workarounds.

A better solution would be to design the Pencil so that a simple quarter twist of the cap would turn it on. That would be a very simple action that would put the user back in charge (pardon the pun) of their device, giving them the freedom to use it however they see fit. Artists could leave it on all day, and casual users like me to could turn it on at will.

I know Apple’s not a fan of anything that adds even a hint of complexity, but sometimes it’s important to account for multiple use cases.

Was this interesting or helpful? Like, Comment, or Share and I’ll write more.

Closing Open Doors by Bringing Vulnerabilities to Resolution – Six Essential Questions

New vulnerabilities are discovered every day,Vulnerabilities and they are an intruders’ best friend. It’s a bit like a burglar finding the door
unlocked and wide open; he’s going to have a really easy day at work and you’ll be wondering for a long time why you left it open.

Therefore, it is absolutely critical to resolve them as soon as possible before they are exploited.

A vulnerability report can be a bit daunting though, especially for a complex solution which relies on many different technologies.  Over the years, I‘ve found that asking these six questions can help bring even the most obscure vulnerability to resolution.

Question #1: Can I remove/upgrade the vulnerable software?
Many times we find a solution is installed with supporting software components that may no longer be required. If this is the case, the easiest way to resolve the vulnerability is to completely remove that component. Best of all, once removed, you no longer have to worr
y about new vulnerabilities presenting themselves in the future for this piece of software.

There are also times that version upgrades may be available for these software components. Upgrading those components to the latest version not only resolves the vulnerability, but also ensures you are working with the latest and fully supported version of that software.

Question #2: Would a configuration change resolve this vulnerability?
Some vulnerability’s cannot be patched, and can only be corrected with a configuration change to the system.

A good example of this is SSL 3.0, an encryption standard used by many web services that has recently been found to be insecure. Changing the configuration of the web service to use TLS 1.2 not only resolves the vulnerability, but also brings the solution in to compliance with PCI and other security standards.

Question #3: Can a security patch be applied?
If the affected software is still supported by the developer, a security patch may be required. If this is the case, submit a request to have the patch installed after testing it thoroughly with your solution.

Question #4: Is the supporting data accurate?
Vulnerability scanners are not perfect, and false positives are a real possibility. Fortunately, the vulnerability report will contain supporting data that was used to determine the presence of a vulnerability. If you suspect a false positive, validate it by performing a manual inspection to invalidate the results the vulnerability scanner provided. If you confirm that it is indeed a false positive, submit evidence to your vulnerability management team to have the finding removed from the report.

Question #5: Can the vulnerability be mitigated?
If the software is current, and the developer does not have an expected release date for a security patch, an alternative method may be required to bring this vulnerability to resolution. This may involve firewall rules to restrict access, or the disablement of non-essential services that would be required for an attacker to take advantage of the vulnerability. Once mitigated, submit evidence of the mitigation to your vulnerability management team to have the finding removed from the report.

Question #6: Is an exception warranted?
There are rare circumstances where a vulnerability must be accepted.  It may be a business process that relies on an end-of-life solution, or the vendor is unable/unwilling to supply a security patch. Whatever the case, when a vulnerability must be accepted it is essential to raise awareness through your vulnerability governance processes. The appropriate security teams can then work to determine what other defenses could be leveraged in to limit exposure. This may involve segmenting the solution from the rest of the network or increasing the visibility of anomalous activity on the solution.