Tom Olzak

Posts Tagged ‘apple’

IDCATU strikes Google, Apple, and Microsoft…

In apple, Business Continuity, Firefox, Google Chrome, Internet Explorer, Microsoft, Safari on February 21, 2013 at 20:47

The Register published an article today describing Adblock Plus angst over Google seemingly trying to take down their ad blocking software on Android.  See Ad-titan Google blocks Adblock Plus in Android security tweak • The Register.

While reading the article, I began to get the feeling that Google is intentionally blocking Adblock because it interferes with Google store functionality.  Interesting…

This is one more reason I am very pis… uh… angry this week.  When I first purchased my iMac last year, I was able to do 99% of what I could do on my Windows 7 laptop.  Today, Google Chrome for Mac is significantly crippled on many sites.  Further, I have to use IE 10 on my Windows 8 laptop to have access to several features I use during research.  We seem to be going backward.

When I started in IT (1983), I encountered a score of different standards from the same number of companies.  It was a compatibility nightmare until business simply accepted the IBM PC and MS-DOS as the de facto standard.  Vendors got on board or went out of business.

During the growth of the Internet, browser choices had gotten to the point that I could use the browser of my choice–the browser I felt most comfortable with–and I could be fairly confident that I would be able to be productive.  This was until recently…

Speaking only from personal experience, I believe I am suffering from a disease spreading across Microsoft, Google, and Apple: IDCATU syndrome.  As it spreads, market share and out doing the competition become more important than user productivity.  Those suffering from I-Don’t-Care-About-The-User use double-talk to assuage the unwary into believing incompatibility between solutions is for their own good. BS.

I am seriously considering moving everything to open source.  The problem is that IDCATU also forces the big players to force the creative and unafflicted to the sidelines.  Some people are simply getting too uppity for their own good… and ours.

Hardware Hacking Defense: Can you say physical security?

In Access Controls, Cybercrime, Data Security, Hacking, Security Management on August 5, 2009 at 11:30

I’ve been sort of stuck in the land of physical security lately.  The reason I can’t seem to extricate my brain relates to the dismal facility security many organizations employ.  It’s the lack of good physical security, including employee resistance to challenging strangers browsing the work area, which makes implementation of hardware hacks a real possibility.

Unlike software keystroke loggers and other nasty malware typically obtained via poor user habits—combined with a lack of Web browsing controls—hardware hacks are virtually invisible to AV software.  (See the vendor agnostic whitepaper, Keystroke Logging at http://ow.ly/jaeU.)  For example, a firmware hack for Apple keyboards was demonstrated at DEFCON 2009.  A related video (http://ow.ly/jahK) shows security researcher K. Chen gathering keystrokes from a laptop via a compromised keyboard.  The main difference with this hack is the ability to take over the hardware without taking the keyboard apart to install a logging component.  However, implementation of the hack is similar to other logging issues—physical access to hardware by an attacker means game over.

This hack, and others like it, require physical access to your computers.  How do you keep bad people away from your information resources?

  • Lock your doors.  Only authorized personnel should have access to your business office.  (If you aren’t securing your datacenter, this bullet is meaningless…)
  • Train your employees to notify security—or management if on-site security personnel aren’t available—when someone they don’t recognize is in the office area without a guest badge.  (This assumes your organization actually makes real employees wear employee badges and guests to wear guest badges.)
  • Make sure your employee training includes social engineering issues.  For example, an employee should know that when a stranger tells him or her that they are replacing the widget control on the computer’s frazzilator, there may be something amiss.  In any case, strangers unaccompanied by regular employees—even if carrying a tool bag—are to be considered suspicious and reportable.
  • Even if a person has a guest badge, unexplained lingering around cubicles or use of an employee system should be reported. If unexplained access was gained to a workstation, consider replacing it.  At least ensure,
    • The keyboard is standard company issue.  (You might consider marking keyboards so they are identifiable as yours.)
    • There are no unusual components connected to the keyboard cable.
    • There is no unexplained hardware anywhere in the cubicle.
    • The Event Logs show no trace of an attack.  (Any attacker worth his or her fees will eradicate any traces of unusual activity–if they have enough time.)
    • Your intrusion detection/prevention logs don’t indicate the PC is sending/receiving unusual traffic.
%d bloggers like this: