26 Jul 2016 |
5 min to read
One of the hardest things when starting a threat intelligence program is deciding where to start collection. This begins with an initial set of requirements and evolves from there. Everyone will give you a different opinion and insist on a different approach probably biased by their favorite collection sources. As for me I think the best approach is to start with the small things, the easy things, and build up from there. What’s easy depends a lot on your organization but this is my general list of useful collection sources for most organizations.
Internal Incident Data
Listen to your enemy, for God is talking.
~ Jewish Proverb
I love this quote and it couldn’t fit this topic any better. If you want to know who your enemies are look at the attacks you’re already experiencing.
The hardest part of threat intelligence isn’t collecting data. That’s the easy part. The hard part is deciding which data is worth collecting. There’s no better way to focus intelligence collection than by focusing on past attacks. This comes from mining internal sources, preferably your incident management system (certsocietegenerale/fir is a good start). Nothing is worse than an attacker using the same resource twice, so when you know a domain is used as C2 then keep watching that domain (and preferably the IP addresses that have pointed to it in the past as well).
Honeypots & The Like (Emphasis on The Like)
I’ll be honest… I hate honeypots. They’re trendy right now (it’s cyclical, like bell bottoms). The idea of letting a bad guy onto my network, even with the intention of gathering more information, scares the heck out of me. My favorite honeypot I ever used in operation was our Active Directory server and while we found it a great collection source it certainly wasn’t our choice. There are some cool tools out there for it, from the classic Honeynet Project to Secureworks new DCEPT project but I’m not sure I’d have the guts to run them.
What is interesting to me is the idea of using passive sources of data to enhance your detection. Want to know your most targeted users? Look at who has the most failed logins. Gathering firewall drops helps you understand what systems attackers may try to access. These passive sources of data provide internal insight that’s difficult to come by otherwise.
While opinions differ I like long form vendor reports. If you can match threat actors up with your organization’s threat model you can learn a lot (don’t assume everything) of what FireEye/Symantec/PaloAlto/etc knows about a given threats. The best reports also include IOCs.
Keep in mind attackers respond differently when outed. Some plow ahead like nothing happened, some change TTPs and even exploits, others shutdown entirely. The Use By date on these is often short, but that doesn’t mean they’re useless. In the end I think they’re free, high signal reports that give insight you might not have access to otherwise.
The cool kid cliques of the network defense world sharing communities are supposedly the end all be all answer to all our security problems. They are not. They’re far from perfect. Perfect though is the enemy of good and these communities do provide a trusted place for sharing threat information. At their most basic these communities can be as simple as a Slack channel. At their most complex they’re built on sharing platforms like ThreatExchange or ThreatConnect.
Getting in is the trick. These groups whether they’re chat or a purpose built threat-threat platform are a mechanism for sharing trust. In most cases this trust is a proxy for real life trust, so take the time to cultivate your relationships.
Why are free feeds my fourth choice? They’re free and all that and everyone talks about them. Well not to be blunt but they’re low signal to noise and generally unfocused. Don’t trust me? Ask smarter people like Alex Pinto & Kyle Maxwell’s Defcon 22 Talk Measuring the IQ of your Threat Intelligence Feeds (Slides & Video). I bet you’ll agree with them.
Paid IOC Feeds
I know I made it last on my list but I’m not saying paid feeds are bad, they’re often great actually. I tend to think of it like a sundae. The ice cream is your first source, your base. The whip cream? That’s when you started mining APTNotes. Rainbow sprinkles… sure I guess that’s your new honeypot.
I view paid feeds as the cherry on top of the threat intelligence sundae. They take a good system and make it great. Take your time, press your vendor, and make sure you can make the most out of whatever feed you get.
The Beginning is the End is the Beginning
Now that you’ve combed through your incidents what’s next? Well we’re quick to forget it but collection isn’t the end of the intelligence cycle, it’s just the beginning. The goal isn’t a list of IOCs. The goal is an analyzed product that meets the needs set out in the requirements phase (you did that too right?). Which hopefully came from output from your feedback phase…
18 Jul 2016 |
8 min to read
One of my goals for this year was getting comfortable with a new programming language. I’ve been a Python devotee for a long time and it’s almost always gets the job done, but I wanted a little bit more. There are times Python works against you:
- Dependency Nightmares: While
virtualenv and a
requirements.txt file work ok for developers it can often make use by non-developers or some deployment stories quite complicated.
- Speed & Scale: This is a funny one. 99% of the time Python is more than fast enough and scales widely enough. Except when it doesn’t. Chewing through a few hundred megabytes of logs? No big deal. Gigabytes or terabytes? Not so much. Hundreds of network connections? Sure. Hundreds of thousands or millions? You might need something more.
- Discipline: Python is easy. Almost too easy sometimes. It lets you cut corners, it takes care of a lot in the background. It’s a great language for getting things done but sometimes I want to learn/control/understand more. Beyond that sometimes I want software that’s more than functional, I want it to be engineered. More structure, more safety, etc.
Working for company made up of largely developers there’s always talk about new development tools and languages. Rust and Golang have been hotly discussed in these circles (along with Erlang/Elixer/Node). I was considering both until I had a discussion at ArchCon with Liam Randall who effused about how great Golang had been for his organization. Good enough for Liam is good enough for me, so I dove in.
What is Golang?
According to the Golang Lanugage site:
Golang is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Go is a strongly typed, not quite object oriented, complied language with a syntax similar to C & Python (with a few little quirks). It’s a complied language (meaning you create an actual binary instead of just running the script like in Ruby or Python). It’s garbage collected, meaning you don’t have to deal with memory management (mostly), and highly concurrent, letting you run multiple threads easily. Golang was built to be a Google Scale language, meaning it’s meant for highly distributed large scale applications.
Ready for code? Here is Hello World in Go:
Simple and easy.
Golang also has a highly developed set of tools that include things like managing dependencies (these get statically complied into your application so end users don’t have to worry about them, just you). There are tons of libraries out there, from a well developed standard library and tons of 3rd party libraries for everything from building websites to using Yara rules.
The result? You get platform specific binaries (running native, without any dependencies) that have speed, scalablity, & safety along with lots useful libraries before you even start. All without having to write lower level, higher learning curve languages like C. Pretty much just what I was looking for.
It’s not all upside. Golang is strict. It has right ways and wrong ways to do things and it enforces those ideas. It is slower to develop compared to Python but in many cases the complications are wroth it.
Why use Golang for security?
I continue to think Python is the best language to start with for Security, but there are situations where you need a little bit more. For me though the first serious benefit was the compiled nature.
I was building a tool that pulled in data from various sources to use on the commandline and with Maltego. Initially these started as Python scripts specifically built for Maltego but they had a couple problems:
- While they worked well enough for me they were buggy, no tests, inconsistent, and often needed me to jump in and fix mid-use.
- The configuration was highly specific to my machine. That’s ok for me, but getting the same transforms setup on someone else’s machine would have been hard. (Yes, we could get a TDS, but for only a handful of people that seemed like overkill.)
- Lastly as useful as it was for Maltego there were times I wanted the output on the commandline instead, to use with other scripts or tools similar to ivanlei/threatbutt. Quite a change to my codebase.
The solution? Well if you haven’t guessed by now I can’t help you, but yes, I began rewriting the scripts in Golang. The result? A single binary that anyone can run whether on the commandline or with Maltego, feels far more consistent and runs on the commandline. It also has the upside of being a bit faster and easier to understand.
Resources for Learning
One fascinating thing about people is how they learn in such diverse ways. Some people like reading while others prefer video. Some prefer diving right in. I’m a fan of a mixed approach, diving into real code, then backing out to learn some theory, then having references while I build. So here’s a little bit of everything so you can build the best Golang curriculum for you!
Hands on Resources
Go is a pretty straight forward language, especially if you’ve done a language like C, Java, or Python before. As a result one of the best ways to learn it is just diving into code itself, play with it, and see how it works. Here are the easiest ways to do that:
- Your first stop should definitely be the A Tour of Go right on the Golang website. This walks through basic core structures with actual runable code, all within a web browser, letting you avoid Golang’s somewhat tedious setup before you know it’s for you.
- After you have Golang installed the next great hands on tool is Exercism.io. This project shares example problems that run live on your own machine using built in Golang tools such as
go test to learn not just syntax, but the tool chain as well. Exercism goes a step beyond by having users collaborate on improving each other’s solutions. Not to mention the Exercism commandline tool is itself written in Golang.
Sites & Blogs
The web is full of resources to help you get started with Golang (almost as much as to help you catch Pokemon). Here are a few favorites:
- Golang.org: The official site of Golang run by the project maintainers this site is a tremendous resource including software, documentation, blogs, and all kinds of other resources.
- Learn X in Y Minutes: Golang I’m a big fan of a good cheatsheet. This is the best one I’ve seen for Golang. It’s the perfect syntax reminder.
- Go By Example: The next step up from a cheatsheet, Go By Example has small digestable topics perfect for those moments you want to see variations on a particular pattern.
- Komand Tech Blog: Komand is a security automation suite built using Golang. They’re taking an open approach and sharing what they learn, including their most recent post Quick security wins in Golang (Part 1).
- Awesome Go: My go to place to find out “Is there a Golang project for X?”. There’s almost always something useful.
- Dave Cheney’s Blog: If there’s a blog to start with it’s Dave’s. He has been writing about Golang since the beginning and has some great lessons. For newbies I recommend starting with Resources for new Golang programmers and Five suggestions for setting up a Golang project.
- The Go Programming Language: This was where I went after the Golang Tour and I still think the best formal resource for learning Go. It’s nicely paced, doesn’t assume too much or too little, and covers everything in the Golang core you’ll need to start building.
- The Little Book of Go: As far as open source books go (yep, it’s 100% free as in beer) I think LBoG is as good as it gets. I keep it on my desktop and reference it often. If I were a student and the $30 price tag of GoPL scared me off this is a very close second.
Projects to Look at!
There are tons of interesting Golang projects out there on GitHub, especially around security:
I also know there’s something awesome coming out soon from Ryan Huber in Go. I don’t want to spoil the surprise, but I’d keep an eye out.
Companies Using Golang
Lots of security companies are making Golang part of their stack (and thus a good language to learn if you want to work for those companies):
And I’m sure more are looking into it. Hopefully you will be too.
30 Mar 2016 |
7 min to read
Requirements. The first part of the intelligence cycle and the most neglected. According to the appendix of Joint Publication 2-0: Joint Intelligence
intelligence requirement. 1. Any subject, general or specific, upon which there is a need
for the collection of information, or the production of intelligence. 2. A requirement for
intelligence to fill a gap in the command’s knowledge or understanding of the
operational environment or threat forces.
Intelligence requirements (or just requirements) are key questions (as @cyint_dude calls them) that stakeholders (the CERT, leadership, etc) want the intelligence team to answer. Requirements set the entire priority of your intelligence cycle, what sources you collect from, what types of processing you need to do, and what methods of dissemination will meet the need. Where your team is focusing, aka Squad Goals. Lets get started…
Past Incident Based Requirements
Effective leadership is putting first things first. ~ Stephen Covey
I’ve said it a thousands times, but place #1 to start is your own incident management system. Build requirements based on incidents you’ve already investigated, every IP address, every piece of malware, every domain. Why do you think firms with consultants who do incident response always have good intelligence? It’s no coincidence, they set intelligence requirements based on the incidents they respond to and so should you. This isn’t ground breaking, so we’ll move on.
Business Plan Based Requirements
If there are two men, Rod and Rob, and you can only steal from one, which one would you choose? The answer is: Whichever one is a banker. ~ Jarod Kintz
The next place to gather requirement is by digging into your organizations business plan. Certain actors target resources in a way that you can rule them in or out of scope:
- Are you a bank or financial institution? Financially motivated attackers probably want to attack you.
- Are you doing energy exploration? A handful of attackers specialize in that.
- Do you invent pharmaceuticals? Look for actors that try to steal intellectual property.
CrowdStrike illustrated this in their Uncover the Adversary map:
So using this as an example (and CrowdStrike vernacular):
- What about that bank? They’ll want to focus on Deep Panda, Impersonating Panda, and Singing Spider.
- If you’re an oil company you should be on the look out for Cutting Kitten, Energetic Bear, and Ghost Jackal.
- The firm with the new heart attack treatment? I’d be on the look out for Deep Panda, Union Spider, and Corsair Jackal.
These distinctions won’t always be perfect but they provide a solid basis to develop requirements. Your industry heavily defines your threat model and thus is a rich starting point to begin defining your intelligence requirements.
Geographic Based Requirements
I get to go to overseas places, like Canada. ~ Britney Spears
Geography is a tricky thing. The Internet lets us access information across the world yet at the same time it’s often an extension of real life. Attackers take advantage of geographic distribution to remain semi-anonymous, but in others they use computer network attack to project a different kind of power within a region.
The Naikon Group is a good example. Public reports say they’re focused on operations within South East Asia. Don’t live in South East Asia? Naikon is probably not interested to you. Living in Singapore? You should probably be paying attention. Even though an actor could strike across the world (and may do so) it would be sloppy to not consider location in defining intelligence requirements.
Aside: Before you say it I agree, VPNs are easy and hotpoints can be anywhere. Avoid assuming too much when it comes to the Internet and physical location.
Technology Based Requirements
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. ~ Unknown
It’s a common mistake to think of attackers as omnipotent. They have limits, budgets, time, etc. As a result most attackers focus on attacking certain kinds of networks. A Windows network running Active Directory is often harder to attack than a Linux network on LDAP (don’t knock MSFT, they’ve invested a lot in security over the last 15 years) but the fact is most attackers are probably more familiar and invested in attacking Windows and AD.
When developing intelligence requirements take the time to look around your infrastructure, what makes you special? Do you run lots of Industrial Control Systems? You should probably be paying attention to different attackers than a law firm running all Macs. Part of this is vulnerability management as well, understanding the flaws that are out there for the systems you protect, but it’s also understanding what attacks can exploit those vulnerabilities.
Vertical Based Requirements
I would rather walk with a friend in the dark, than alone in the light. ~ Helen Keller
One of the least appreciated approaches to forming intelligence requirements is asking others. Backs work with banks on similar criminal groups. A university could collaborate with similar universities by sharing information about incidents. Industry has been embracing this for years with the formation of Information Sharing and Analysis Centers such as FS-ISAC, the Retail Cyber Intelligence Sharing Center, and others. Whether formal or informal these groups provide the chance to learn from others and avoid making the same mistakes twice.
One Off Requirements
Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. ~ Donald Rumsfeld
Then there are the odd bits. They may come in when a higher up is watching CNN in the airport or they may come from a spooky government source. No matter what they will show up at some point and become part of your intelligence requirements, maybe as a one time addition, maybe on an ongoing basis. Don’t discount them.
Writing Strong Requirements
The best intelligence requirements are specific enough to direct answering the question. Here are some characteristics that lead to good intelligence requirements:
- Singular: A strong requirement focuses on one question and only one question.
- Atomic: The requirement should be specific to a particular fact or event.
- Decision Centric: The requirement should lead to making a decision.
- Timeliness: A requirement should capture the timeframe for usable intelligence.
It takes time and practice to develop good requirements.
| Weak Requirement
|| Strong Requirement
|What actors might attack our company?
||Is X Actor active?
|What indicators should we be using in our IDS?
||What are current file system indicators of Actor X?
|Are there actors targeting the location we’re in?
||Is an actor specifically targeting Region Y?
|What malware should we look for on our network?
||Are attackers using Locky against my vertical?
|Will our organization get DDoS’d?
||Are there indicators of DDoS attack in the next 30 days?
Practice makes perfect, but working with others to sharpen your requirements writing is even better.
Just the Start
Even though they’re commonly missed the fact is developing good requirements sets the solid foundation for a good intelligence cycle. If you want to read more the CIAs Center for Intelligence Studies has a great article A Fresh Look at Collection Requirements and
Army Field Manual 34-2 Collection Management to Support Commanders includes the appendix Developing Priority Intelligence Requirements. Read those and you’ll be on the right track.
26 Jan 2016 |
4 min to read
I admit it… I’m a fanboy. A straight up osquery fanboy.
Oh… what is osquery you ask? Good question there sport.
osquery allows you to easily ask questions about your Linux and OSX infrastructure. Whether your goal is intrusion detection, infrastructure reliability, or compliance, osquery gives you the ability to empower and inform a broad set of organizations within your company.
That’s how Facebook describes it. I’d say osquery is the most effective way available to monitor an OSX or Linux host for security. But that’s just me. Still not bad no matter which definition you prefer.
The big question everyone asks though is how do you get started with osquery and so without further ado:
This one is pretty simple. Just follow these handy instructions.
OSX Side Note: If you’re on OSX and a fan of Homebrew (as I am) you’ll want to skip Homebrew this time and install the package directly. Homebrew gets weird about running things as root later on, and that will be a pain. Safe yourself the pain.
osquery provides two main interfaces to the user: osqueryi and osqueryd (we’ll get to osqueryd in another post). osqueryi is a REPL (Read-Evaluate-Print Loop) similar to
$ irb or
$ python. This lets you input a command and get back an immediate response. We can use this for a few things:
- One off, spot checking of specific system attributes.
- Developing new queries.
- Learning your way around osquery.
So lets give it a try. Get started by typing
osqueryi at your terminal.
osquery… uh… queries
Now that you’re at the prompt you’re ready to start looking for things. osquery uses the sqlite query language for simplicity and descriptiveness. The most basic query format is:
> SELECT columns FROM table;
Don’t forget the semicolon “;” at the end of your query! You wouldn’t like it without the semicolon. In that it won’t do anything.
For example lets take a look at the OSX kernel extensions I have installed:
Ok, so that found the data I wanted, but a bit too much. Every OSX system has Apple written kernel extensions, which makes those less interesting. Using the sql concept of a where clause we can limit this just to non-Apple kernel extensions:
Much more useful. Lets take it one step further and make it more readable with sorting:
For those playing at home you can see I have 11 kernel extensions for 5 applications (and OSX itself). The final query that got this information is:
> SELECT name FROM kernel_extensions WHERE name NOT LIKE 'com.apple%' ORDER BY name;
Pretty straight forward, but by now the power should be evident. As you practice more you can express powerful and complex ideas using this syntax. For more on syntax take a look at the SELECT documentation for sqlite. This coupled with the osquery Tables reference will give you most of what you need. A couple of key, non-query, commands will help you get started:
|Gives you the osqueryi help dialogue
|Prints the table columns and data types
If you want some examples of what you can look for and how you can use the sqlite syntax take a look at the osquery Packs. Here are a few of my favorites:
Incident Response: open_sockets
> select distinct pid, family, protocol, local_address, local_port, remote_address, remote_port, path from process_open_sockets where path <> '' or remote_address <> '';
A typical SELECT FROM WHERE style query to find open network connections. Combine this with an IP blacklist to identify C2 activity.
Incident Response: startup_items
> select * from startup_items;
Startup Items is a common way for OSX malware to persist between restarts. Most users don’t even notice it’s there.
Vulnerability Management: chrome_extensions
> select chrome_extensions.* from users join chrome_extensions using (uid);
Chrome extensions have a scary amount of access, especially in web based workflows. They’re worth investigating.
Want to Learn More?
I do too. There’s a lot to osquery. It’s not a solution, it’s a framework. On one hand that makes it customizable, on the other that means many parts of using it are left to the user. It may be free, but that means it’s an investment of time rather than money.
Kevin Thompson and I spoke about osqueryi and more at BSidesDFW 2015:
I’ll explore some of these ideas from our presentation in the next post in this series: osquery 110 - Programmatic osqueryi.
20 Jan 2016 |
11 min to read
Last year I was lucky enough to go to the FIRST2015 conference in Berlin. It was a great conference, good talks (including yours truly), and an even better hallway track. I’d never been to Berlin, or Germany in general, and I enjoyed seeing this amazing city a little bit as well.
Traveling to a new country as a security minded person is always a bit jarring. Even a country as friendly as Germany bares consideration when it comes to laptops, tablets, phones, etc. A conference like FIRST has people coming from all over the place, including people from countries at odds (US, China, Iran, Germany, etc). As a result those IT security concerns are even more heightened. As a result we ended up having some academic conversations about operational security while traveling internationally (or traveling generally).
Traveling internationally has some unique challenges compared to using IT resources at home.
Running around a new country one of the first things you might notice is powering your devices can be tricky. Plugs are different, voltages are different, and you may not have the right adapters. A good travel battery can help, but at some point you’ll be hunting for an outlet to grab a charge.
Home is where the wifi is, but when you’re traveling you have to take what you can get. You have to balance security with the need to connect. Random coffeeshop/airplane/hotel wifi are all viable pipes, but under who’s control?
You’re in an exotic (or maybe not so exotic) place and you want to get out and see it. Go out to dinner, site seeing, etc. You’ll want the freedom to do that, and you can limit yourself by how much you feel the need to carry.
The first question for security should always be “What is the threat?”. If you’re basing your security stance on anything but practical threats then it’s just FUD. While people exaggerate threats often in this case their seems to be plenty of concerns.
Seizure at Checkpoints & Evil Maid Style Attacks
Depending on the country customs seizing devices at check points, either for minutes or days, may happen a little or may happen a lot. But it does happen. A close relative of checkpoint seizure is the evil maid attack, where someone with access (like a cloned keycard) enters your hotel and accesses your devices while you’re out of the room (Oh, and they might also have cameras + listening devices in your room as well, just in case you fall into a honeypot).
The basic formula of both of these attacks is physical access + time = compromise. Full Disk Encryption helps, but it’s not bulletproof given near infinite computing resources and near infinite time. If your computer leaves your site at a checkpoint assume the data is staying.
Dark Hotel Style Attacks
Moving past physical attacks there are other ways to steal data in hotels. The DarkHotel APT group targets victims by compromising the networks of common traveler destinations such as international hotels and uses their access to infect victims with trojans, pilfering data at their convenience.
Power seems at most partially related to security, but USB based charging is common for tablets and phones even laptops. For certain advanced attack groups USB device attacks are a way to compromise offline devices. Plugging a device into a USB charging dock in an airport or into a new friends laptop is an easy way to get an extra 10% power, but risks picking up malware or syncing your mobile device and handing over all the data on it.
Theft & Loss
Simple and boring but no less real, IT resources get lost all the time. Cell phones get left in cabs, laptops get stolen in cafes, all happen, and all pose a risk. It’s hard to stay backed up on the go and it can be extra difficult to recover these devices on foreign soil.
I’m not going into this one, but it happens.
The Plan: Rules for International Travel OpSec
So now that we’re clear on the challenges & threats, at least the big ones, lets discuss the solutions.
International Travel Rule #1: LEAVE IT AT HOME!!!
I cannot emphasize this enough. If you don’t have it with you it cannot be compromised, the data cannot be stolen, and you don’t have to worry about it. Far and away leaving it at home is the lowest risk approach. For alternatives where you need to take your laptop see step #2 but prepare yourself: These things are a pain. They’re difficult. And they must be.
International Travel Rule #2: Prep It Before You Leave
You actually have to take a laptop? Are you sure? Well if I can’t convince you otherwise at least be cautious. An ounce of prevention is worth a pound of cure, so take some time to get things ready.
Loaners & Alternatives
Borrower laptops are a common approach and are certainly better than taking your usual laptop but I’m still not crazy about them. While they may limit exposure they have three failings:
- To make them useful they still get loaded up with some (if limited) data (the whole thing we want to avoid).
- They aren’t inherently harder to compromise than the users own laptop.
- Since they aren’t the users own system the user is often less careful with it, resulting in risk.
To this end the CrowdStrike team released some of their scripts for setting up an ArchLinux laptop for travel which looks like an solid solution for setting up loaner laptops.
I’m a far bigger fan of devices like an iPad or Chromebook for travel. They’re easy to wipe & reset, don’t store much data, designed to resist attack, and cheaper than a full laptop.
They’re also both super light and get great battery life. All but the most dedicated road warriors don’t need more than a browser for most travel use anyway.
Everything… and then double check:
- Operating System
- Applications (Focus on the applications you use every day and common vector apps like Adobe Acrobat & Reader, Microsoft Office, Flash, your browser (or just switch to Chrome and update that))
- Secondary tools (Like Browser plugins)
Don’t forget your “other” devices like phones, Kindles, etc.
You already have two factor authentication turned on every where you can right? Well double check and make sure. TOTP based is great, but YubiKey is becoming even more attractive as services are beginning to support the FIDO/U2F standard. I’m also a big DuoSecurity fan for it’s great interface, easy integration, and reasonable prices.
Setup a VPN
Setting up your own VPN isn’t that hard and provides a lot of trust and flexibility, even if it comes with some extra effort. While you’re at it take the time to enable DuoSecurity as well.
You could also use a paid VPN provider. The downside is placing your trust in another service but the upside is it’s easy and often comes with more polish. I like Cloak for it’s clean design and multi-device support.
Privacy Screen Cover
3M makes some nice privacy screen covers. I have one and it’s great.
Pretty huh? That said I’m still mixed on them. While it does a great job of keeping your words from the person sitting next to you it also draws attention. People wonder what you’re trying to hide which makes it a double edged sword. Avoiding the gold side helps.
Charging USB devices off of random USB charging stations or someone elses laptop is convenient but runs the risk of exposing you to USB transmitted malware or accidental syncing.
A USB condom (sorry for the uncouth term Mom) protects you by breaking the data transfer connections of USB while leaving the power connections intact. That means you can charge your device without inadvertently syncing data or worse.
SyncStop makes a very nice device.
International Travel Rule #3: Be Aware of your Surroundings
I don’t know how to suggest how you do this, but you need to do it. That’s not super helpful, so I’m doing what anyone does, Googling it. I recommend reading this article from Psychology Today on Becoming Aware. If that isn’t ninja enough for you I suppose you may want to read the articles tagged “How To Become Aware of Your Surroundings” from the WayOfNinja but I don’t recommend it.
International Travel Rule #4: Carry Your Devices with you At All Times
I told you this would be a pain. This basically goes directly against the mobility concept we started out with, but it turns out it’s highly important. Two of the threat types we discussed require physical access and the way to be sure is to have them with you at all times.
That doesn’t mean except for dinner. That doesn’t mean unless you want to go for a walk. Always. I recommend getting a bag you find comfortable for long periods of time, the lightest devices possible (or, you know, just leave it at home like I suggested in the first place). Which devices do you need to carry? My rule of thumb: if it has a USB port or network access you can’t leave it.
Note: This doesn’t make physical attacks impossible, it just makes it impossible for you to not be aware. You’re not a SERE school grad (unless you are in which case good for you) and if someone wants to take your devices they will. At least you’ll be aware and able to tell your security team what happened.
International Travel Rule #5: Keep Things Turned Off & Logged Out
Once you rule out physical access the only attack vectors are Wifi, Bluetooth, etc. It’s inconvenient but it works wonders, otherwise you may find yourself randomly connecting to unknown Bluetooth devices or wireless networks. This goes double for borders.
So lets say for some reason you really, actually, insistently must take a full on laptop to a foreign country. To make matters worse it’s one that’s passive aggressively hostile towards yours. Well in that case you’ll want to do some serious system hardening. Your goal is to remove as much attack surface as possible and beef up the things you must have exposed. I mostly use OSX, so here are a couple of the better hardening guidelines for Macbooks:
There’s also this lock-down tool by the always awesome Scott Piper:
I haven’t used Windows for years, but I know EMET is pretty great (I’d love to see an EMET like kit for OSX) and Microsoft has invested a lot into making Windows 8 & 10 hard targets. For anything else I’d take a look at DISA’s Security Technical Implementation Guidelines or the NSA/CSS Security Configuration Guides for Operating Systems.
This is far from a comprehensive guide to safe traveling. The world is a dangerous place. Hopefully though this gives you some ideas on how to level up your IT security while traveling. The world is an amazing place, I’ve been lucky to see as much of it as I have and I can’t way to see more, but a little consideration goes a long way.
And one last time: Just leave your laptop at home. You’ll be fine. And you might experience something amazing.
If you want to go further I recommend reading Jeffrey Carr’s A Traveler’s Guide to Cyber Security).