AWS Lamba and My Amazingly Cheap Experiment

Earlier this year, I found myself in need of a little monitor.  To be more specific, there's this artistic fellow who puts "limited number/run" stuff up for sale on his website at seemingly random times.  And I've missed the opportunity to purchase some of his stuff because I didn't realize it was up for sale (bummer!).  So I wanted something automated to check his website frequently and alert me to any changes.  This situation looked like a great excuse for me to try out AWS' Lambda offering.

Enter the Lambda

Introduced in 2014, Wikipedia describes AWS Lambda as "an event-driven, serverless computing platform" which is a compute service "that runs code in response to events and automatically manages the compute resources required by that code".  Lambda is designed so that you don't have to provision it yourself (Amazon automagically handles where your code runs), billing you only for the time your Lambda function (i.e. code) takes to run.  Since its inception, Lambda has grown to support a number of different event triggers and interacts with many different AWS services.

In my case, I wanted something trigger by a timer that would go check the website and see if new items for sale had been listed.  And Amazon had a tutorial which got me 90% of the way there right out of the gate.  Perfect!

The Tutorial Flow

The lambda-canary "blueprints" AWS offers are Python code snippets which will go check a website and throw an error if there was a problem reaching or loading the website.  Using a periodic timer setup in AWS CloudWatch, the Python code is executed at whatever frequency you've selected.  If an error occurred reaching or loading the target website, the code will raise an exception.  This exception gets caught by CloudWatch monitoring, who will increment the "error" metric count, triggering an alarm you've set up for when errors >= 1.  And this alarm triggers the SNS alert you setup, so you get an email or text or however the SNS is configured to message you.  Not too shabby!  I tweaked the Python code a bit in my case to look for specific strings of text in the loaded webpage ("coming soon", "out of stock", etc.), and I was good to go!

The Cost

So having a little Lambda function to check a website every minute of every hour of every of every day of every week (etc.) turns out to be REALLY cheap.  Here's how billing during my first month of running looked:

To be fair, it did end up costing $0.02 for my first month of March (Amazon's mid-month forecast was off by a penny, dang!  :P  ), but has been usually $0.01 per month since.

Wrap it Up Already...

My experiment has been super cheap and really fun (and allowed me catch those artist's items I had been missing out on!).  I have some improvements I'd like to make, or course, but it's mind boggling to me just how inexpensive it is to run a task like this.  While Lambda won't lend itself well to some types of tasks, it does appear to be a very nice option for those it does!

"I don't know that number..."

Miss the olden days of Caller ID, where a caller's number (with name!) would magically appear after the first ring or so?  I miss that feature when I get a call from a number that's not already in my contacts list (although I must admit that Google's Project Fi does a nice job on proving a name for some calls I receive that don't match existing numbers in my contacts list).

A friend of mine recently clued me into a cool online site for phone number lookup: https://www.twilio.com/lookup (Twilio actually provides many call-related services, lookup being just one of them)  You go the web site, plug in the phone number, and Twilio will attempt to tell you the name on the account, the carrier associated with that number, if the number is associated with a mobile or land line, the originating country for that number, and more:

It's worked pretty well for the handful of numbers I've tried so far.  And it seems they allow free lookups (at least a handful, anyway), but the paid model is a modest $0.01 per lookup (not shabby).

Traveling Securely

With the summer break here, vacation time is kicking up.  Whether you're traveling across town or around the world, there are steps you can take to protect yourself and reduce your "attack surface" (i.e. the ways you are vulnerable).  Below are some suggestions  (not an exhaustive list here) for your consideration, applicable for both personal and work-related travel (and even your day-to-day when you're not traveling!).  Obviously I don't know everyone's needs/requirements, these are just some general thoughts.  And links-to or discussion-of specific products/services shouldn't be taken as an implicit endorsement, rather just as examples.  😊

Travel Light (a.k.a Don't Bring What You Don't Need)

This applies to both tech and non-tech items.  Don't need your checkbook?  Don't take it.  Not visiting the remote work office?  Leave your work ID and/or access badge(s) at home.  Passport not required?  (this one might be tricky these days...)  Don't pack it.  Not doing work while on vacation?  Leave the work laptop locked up at home or in your office desk.  Reducing the items you're carrying not only makes your bags lighter, it's "one less thing" to worry about losing or getting stolen (and the subsequent stress of phone calls and emails you'd be faced with making in such a circumstance).

Protecting What Comes With

This can be (and is!) a long list of stuff.  It'd be a lot for folks to follow every suggestion below, but the more you follow, the better-protected you'll be.  And this is not to suggest that the baddies out there will come at you from every possible angle (well, unless you're really that interesting of a person!  I, myself, am not...), but evil-doers just need one weak spot to get at ya...

• update the OS, applications, and AntiVirus definitions on your devices before you go
• keeping your laptop, phone, tablet, etc. devices updated will prevent folks from taking advantage of older bugs/vulnerabilities to gain access to your device
• securely back up your data before you go
• if a device gets stolen or seized by a government official, you'll still have a copy
• only charge your devices from your own chargers and/or battery-packs
• you'll avoid "juice jacking" this way, but if you absolutely must charge off something you don't own, use protection (or a cable you own that you are certain is a power-only --no data-- cable)
• don't connect unknown devices to your devices
• that USB drive you found on the hotel lobby floor doesn't contain anything worth the risk of infecting your laptop, trust me
• securely delete sensitive data from portable data devices
• don't leave that copy of your tax return sitting on your USB thumb drive
• disable wireless technology that your devices aren't using (Bluetooth, WiFi, NFC, etc.)
• the fewer you use, the fewer ways for an attacker to get at you
• don't connect to unknown, unsecured/"open", or poorly secured networks
• ideally use networks you know which are using WPA2 for security
• connect to a VPN when using public, hotel, and airport networks
• VPN offerings like Tunnel Bear are affordable and work on Windows, macOS, iOS, and Android
• avoid logging into personal accounts from devices other than your own
• keyloggers or credential stealing software might be present, but even a leftover cookie from forgetting to log out of your gmail is all someone needs
• use multi-step authentication (good) or multi-factor authentication (better) for your device and online logins
• there's a slight difference between the two, but doing either one of them is better than using neither of them
• ensure your stored data is encrypted
• modern operating systems (both computer and phone/tablet) make this super easy to do, where you won't even notice the data is encrypted (but someone stealing your data will notice when they can't decrypt the data to read/use it)
• store items which contain a passive RF component (e.g. U.S. passports, work badges, drivers licenses) or an RF transmitter (e.g. fobs for keyless push-button ignition vehicles) in a protective case/enclosure
• prevents attackers from reading your passport info as they brush (or drive!) by you or from stealing your vehicle while you shop
• keep an eye on your accounts that you're using for payment while traveling
• if using credit or debit cards, beware of account-info-stealing skimmers and shimmers on ATMs, gas pumps, and the like
• be aware of your surroundings when entering credentials or viewing sensitive information
• is anyone looking over your shoulder, or maybe there's a camera installed somewhere (like in the shimmer article link above) 
• always log out of online sites/services when you're done using them
• in the event someone obtains your device, your logging out from these sites prevents them from accessing those accounts
• always lock your device when not in use
• it might be annoying to unlock that tablet every time you use it, but it will keep a thief from easily getting at your sensitive data
• enable "find my device" capability on your devices
• has helped find many stolen/lost devices over the years
• enable "remotely wipe my device" capability on devices which contain sensitive/personal data (or have the credentials stored to access sensitive/personal data)
• in the event you can't find the device (or it's not practical to try and retrieve it), use this tack to erase your data from the device so you don't worry about others getting ahold of your data

Protecting Your Person

Decidedly shorter list here (because I'm less knowledgeable in this area), but a few points for your consideration:

• prefer "known secret" (e.g. password, drawing pattern, image sequence) credentials to biometric (e.g. fingerprint, face recognition) or device-based (e.g. USB/Bluetooth/NFC device possession)
• while it is convenient to unlock your phone with your fingerprint, it is usually more difficult for the U.S. government to legally compel/force you to unlock a device if it is secured by "something you know" (e.g. a password, an unlock pattern, etc.) rather than "something you are" (biometric) or "something you have" (NFC keyfob)
• carefully dispose of items containing sensitive/personal/account information
• securely shred them or carry them home with you to securely dispose of later
• know your rights
• check out the American Civil Liberties Union and the Electronic Frontier Foundation

But All This Sounds Like a Hassle!

Yeah, it kind of does.  But it you choose a few items here to implement in your life and get use to them, then add a few more, get used to those, etc.,  hopefully they'll be second nature before you know it (and your data, devices, and life will be more secure!).  As the old adage goes: "an ounce of prevention is worth a pound of cure."  

Firing Things Back Up...

This month marks one year that I've been back to working in the security space.  I've been having a ton of fun and constantly absorbing stuff (part of the "fun", yo), and also thinking on how I might share some of what I've learned in a consumer-friendly fashion.  So, hey, what about my dinky blog space I've been neglecting for years?!?  Sounds good!!!  :P

Starting today, I plan on posting somewhat-regular (not more often than weekly) entries on different aspects of security, with a particular focus on personal security.  Take note: I do NOT purport to be any sort expert, and anything offered here is strictly MY PERSONAL OPINION (and subject to change, particularly with the shifting landscape that security tends to be).  That said, I'm open to other's thoughts and questions folks might have, just hit me up in the comments!

Onward!

Felix is Da Man!

And so are Joe and the folks at team Red Bull Stratos!!!  Just a while ago, Felix Baumgartner jumped from a capsule floating ~128,000 feet above sea level and free-fell for over 4 minutes back to earth.  In the process, he broke several records (some of which have been standing for more than 50 years!) and he made it back to terra firma safely.  The jury is still out on whether he broke the speed of sound or not during his free-fall, and he did have some difficulty with his visor heating (it also fogged up during his descent, possibly related to the heating issue, I reckon), but what a fun/amazing thing to watch!

Congrats, Red Bull Stratos!!!

Embedded Development is Only Getting More Interesting

With the perpetual trend of more-processing-power-for-your-buck, the space many folks refer to as "embedded" is just getting more and more interesting on the high end.  Processors like the i.MX from Freescale and boards like the Raspberry Pi (both ARM based) can handle a full operating system (like Linux, for example), as opposed to a basic event loop or traditional RTOS.  In addition to providing developers with more "cool things one can do" by having a full OS running, this also opens up a new development "flow": building directly on the board.  It goes like this:

• write some code
• compile-and-link it on the OS running on the board
• run it!

Where before you would need a toolchain with a cross compiler, these embedded devices are now mature (and powerful) enough to support running their own toolchain directly.  You can also do fun things like rebuilding the board's kernel directly on the board!

Another cool development flow which has also gotten popular over the last 5 years or so: building code for embedded devices within a virtual machine (VM).  This flow follows the "cross compiler" model, in that you use a toolchain running on a development platform of different hardware and/or software than your target, embedded device.  But the twist is that the toolchain is installed in its own OS instance inside a virtual machine.  This is very nice because you can use whatever OS you normally like to use (Linux, Mac OS, Windows) as your "host" OS, and then create a "guest" VM with whatever OS and toolchain you need without affecting the "host" OS.  And there are many available-at-no-cost Virtual Machine programs available, too (I personally use VMPlayer under Windows most of the time).  Many developers used to install two-or-more OSes on their development system and dual/multi-boot between them in order to satisfy the need for having a specific toolchain running in a specific OS for doing embedded development, but the use of virtual machines removes the need for having to reboot: multiple OSes can run simultaneously, making it very easy on a developer to get things done (I can tell you from personal experience that having to stop my development so that I can reboot my laptop just so I can check my Outlook calendar for an upcoming meeting notice is very disruptive).  Also, this development flow isn't just awesome for embedded development, it's great when you need to compile code for a different OS that runs on similar hardware.  For example, I can install a 64-bit FreeBSD VM image on my x86 64-bit Windows 7 laptop, write code and compile it there in the VM, copy the generated executables to a x86 system that is running 64-bit FreeBSD as its OS, and it works great!

Seriously, this is cool stuff...

The Pi Has Landed!

Been busy lately, but I got real excited to see my Raspberry Pi show up this week!  Newark/Element14 shipped it from South Carolina, arrived in a plan brown envelope with no additional fanfare other than my anticipation...

The board in all its glory!

I downloaded the "wheezy-raspbian" (Debian based) recommended distro (at least recommended to start with), loaded it onto a SD card, popped that puppy in, connected a USB keyboard and mouse, added a network connection, then added necessary power (micro USB supply) and video (HDMI; hooked that bad boy up to my 46" Sony LCD TV), and fired it up!!!

After the usual Linux (3.2.0 kernel) boot messages (as you can see, they didn't quiesce them for this distro, which allows for easy checking of how things are going during boot), you get a nice little ncurses menu.  This menu allows you to do usual things, like set timezone and keyboard type, but also contains handy options, like expanding the rootfs to fill the SD card (so, in cases like mine where my SD card was much larger than the image I loaded, users can now recoup that free/unused space leftover on the card as usable filesystem space!).

Boot time!  The little LEDs closest to the bottom are the Pi!

After this menu, you get the usual Linux command line.  I was able to see, via ifconfig, that my Raspberry Pi had DHCP'd an IP address from my router and could name-resolve and ping google.com!!!  I then ran startx to get the full UI up!

This distro uses the lightweight LXDE interface, which looks great and handles well.  Preloaded on this distro are several lightweight web browsers and some "fun" programming stuff (like Scratch!).  I had no problem firing up one of the web browsers (Midori) and surfing around.

The UI provides tasty Pi experience!

I'm looking forward to digging a little more into the Pi's capabilities and figuring out how/where I might use mine!  :)