Author Archives: Patrick O'Connell

About Patrick O'Connell

Security Engineer with ten years experience in large-scale system security. Focus on SIEM-based workflow automation and incident detection.

Value is in the Eye of the Beholder

When I am working with clients, sometimes the hardest lesson is in calculating the value of information. Part of this is the difficulty in figuring out the risk calculations that determine appropriate care. The secondary part is figuring out what others think that information is worth, to determine the chance of being targeted in an attack.

Sometimes you get to know how valuable the information you control is. The Federal Reserve, for instance, knows that the data they release is worth for a fortune. As a result, they set up elaborate security for each report release. Despite this, timings from trades related to the “no taper” decision announced in September 2013 indicated that it still managed to leak early.

When you know that value, you still want to know how people would acquire it. The technical term for this is penetration testing. This is when an outsiders are paid to pose as attackers, and gain all the access they can in order to illustrate the methods that the client is vulnerable for. A good example of this can be found in the description from Adam Penenberg. The technical explanation from that same story can be found in a writeup from his attackers.

What makes this much harder is when you don’t even know what is valuable under your control. These are circumstances where the information you control becomes much more valuable to a given attacker. Examples of this can be pulled from the the attack on Mat Honan. There, the value was found in the mere knowledge of his email address, and then the last four digits of his credit card address, which Amazon displays once the account is compromised.

This illustrates how “trivial” information can have great value to the right audience, and why data security needs to be confirmed for all information under control and not just that which the controller believes to have worth. You will be compromised not for what you think is important, but for what your attackers decide they want. When you plan around everything having value, you can plan better how to protect yourself and those who depend on your business.


Enhancing Browser Protection with Sandfox

In my own infrastructure, I use Sandfox to enhance my web browsing security. This is a Linux and OSX tool that creates a secure chroot, to ensure that even if your browser is compromised, it cannot access critical files. While I use it with Firefox, in theory it can be used to sandbox any application.

Before I do anything, I create a limited user who will only be used for web browsing. You should have pwgen installed before running this command or replace that part of the command with another long, randomly generated password. You should never log into this account.

# For the rest of this tutorial, that user's 
# name will be "USERNAME-sandbox".
useradd -m -p `pwgen -sy 30 1` "`whoami`-sandbox"

Once you have done that, you may initialize the sandbox.

# Create a Firefox sandbox but don't start Firefox
sudo sandfox --profile=firefox

For instance, I have mine configured to only have access to a specific downloads directory. That way you can control where any file goes, and ensure it does not just end up in your home directory where it could do more damage if exploited. Remember to ensure that the sandboxed account has write permission and your user account at least has read permissions to this folder.

# Add an additional bind to an existing sandbox named "firefox"
sudo sandfox --sandbox=firefox --bind /location/of/download/directory
# Force update of the firefox sandbox after editing its profile
# to add new binds.  (missing binds will be added, but existing
# binds will NOT be removed)
sudo sandfox --sandbox=firefox --make

Once that is configured, I alias firefox in my profile to ensure that whenever I launch it, the sandbox will be created. You should change the file modified to reflect what shell you use, I use zsh. Also ensure that you modify the alias to use the correct username, generated in the first step.

alias firefox=gksudo sandfox --profile=firefox --user=USERNAME-sandbox /usr/bin/firefox

This adds another layer of protection, although it is not insurmountable to an attacker. Anything you allow write access to can potentially be modified by a successful attacker. Sandboxing can work in Windows as well, although I have not used any of the options available and therefore cannot make any recommendations.

Economics of Malware: Presentation

Thanks for those of you who have been following my series on the economics of malware (part 1, part 2, part 3). I presented about that topic at Madison’s Nerd Nite today (October 30, 2013). This is the presentation, along with notes necessary to give it. It is available under a Creative Commons – Attribution/Non-Commercial/Share-Alike license.



For over a decade now I’ve been responsible for maintaining security resources and advising Sophos customers and partners about security best practices.
I also do a fair bit of public speaking for Sophos on emerging threats and protection strategies and am always in contact with IT professionals and end users.
What I haven’t done so well is make sure that those closest to me get the same benefit from my experience.

So here’s a checklist of what I did.

via Security begins at home – how to do a “back to basics” security overhaul on your family network | Naked Security.

This is a good addition to my previous articles on personal and wireless security. It offers a few other backup options to consider. My only major issue with the article is how it only suggests encrypting backups in the cloud. Data should be encrypted in all locations, especially those outside your total control. Despite that, it is overall a short, useful checklist.



Now that we have enough details about how the >NSA eavesdrops on the Internet, including today\’s disclosures of the NSA\’s deliberate weakening of cryptographic systems, we can finally start to figure out how to protect ourselves.
For the past two weeks, I have been working with the Guardian on NSA stories, and have read hundreds of top-secret NSA documents provided by whistleblower Edward Snowden. I wasn\’t part of today\’s story — it was in process well before I showed up — but everything I read confirms what the Guardian is reporting.
At this point, I feel I can provide some advice for keeping secure against such an adversary.

via Schneier on Security: How to Remain Secure Against the NSA.

I’m split preparing for presenting at Madison, Wisconsin’s Nerd Nite on October 30, 2013. Schneier covers several important notes as to how to handle security in general against a state-level actor, but the lessons are useful to implement in general.

Lesson three in particular is valuable. If you assume someone CAN be listening to your activity, it is easier to avoid doing something stupid. Where you should be worried about being discovered, act on those fears. Air gaps or one-way network connections can protect confidential information better than any firewall.


Obscurity itself, however, when added to a system that already has decent controls in place, is not necessarily a bad thing. In fact, when done right, obscurity can be a strong addition to an overall approach.

via Security and Obscurity Revisited | Daniel Miessler.

This is a good exploration of why “bad” defenses can still help, if used in addition to “good” defenses. As long as the additional layers do not undermine known-good policy or procedure, add them.

The Economics of Malware: Governments

Note: This is the third of three articles I will do about the economics of malware. I will be giving a presentation on these issues at Madison, Wisconsin’s Nerd Nite on October 30, 2013.

In part one, I talked about the history of vulnerability research, and the development of the market that exists around them. Part two involved the criminal side of the purchasers of those vulnerabilities, and how they make their profit.

Today’s subjects are those who operate with a level of sanction. These are government agencies and contractors, all of which operate with different goals than the criminal elements discussed in part two. Broadly, those goals fall under three categories.

  1. Monitoring their own Citizens – This goal applies to any instance where the government or its agents (public or private) act in order to observe people under their banner. This can fall under censorship desires, such as the Chinese Great Firewall of China being used to control what is discussed. Alternately, they can be under the guise of law enforcement Saudi Government looking for technologies to “monitor terrorists“.
  2. Gathering Information from outside their Borders – External espionage is perhaps the most common governmental use of malware. In this case one of the best know examples is Flame. The control servers used in Flame(r) left lots of evidence about its longevity (perhaps five years) and extensive data collection (upwards of 8gb of encrypted data in a mere 10 days). This is far from the only example, however. as the Chinese government has used similar tactics in order to gain data on weapons programs.
  3. Disrupting Targets – For instances like this, the attacks can be more direct. The quintessential modern example is Stuxnet. With these, governments (assumed to be the United States or Israel, or both), created some of the most successful malware packages. Stuxnet was used to (supposedly) slow the Iranian nuclear weapon program by disabling centrifuges used to enrich uranium. There also exist examples of North Korea launching overt attacks against South Korea, or rumors of Iranian involvement on attacks on financial institutions within the United States.

As with all things, these goals unify with the overall desire to increase the power and influence of their constituent nations. With that in mind, they work in different ways from the criminal element. Luckily, the multi-prong form used by the NSA can be used as a case study.

These are examples of how modern governments are major purchasers of exploits, just like the criminal elements of part two. Once purchased, they go to use. The NSA has used and is preparing for expanding malware use. One of the United State’s ongoing major programs is to develop better techniques and methods for handling large scale assaults.

The attacks begin at the network layer. Most people depend on the appearance of a lock in their address bar to know that they have SSL protection when they browse the Internet. At some point, the NSA compromised the value of SSL, TSL, and VPN, at least on some level. Attacks on alternate anonymization technologies assist them in ensuring they can collect data especially those who want to hide themselves.

In order to do so, they used multiple methods. First, they used the extensive collection of zero-day vulnerabilities they acquire either through their own research or the gray market that exists today. Additional work is farmed out to contractors, expanding what is perhaps the greatest growth industry in defense. They also pay employees of major tech companies to insert backdoors that allow them access.

Works spill over into other arenas. Importantly, the NSA use of malware and exploits has led to fear of legitimizing their utilization, although that appears to be a moot point. While governments such as Germany show anger at the revelations of the last year, they are also not innocent of using their own similar tools.

The biggest issue here is that as more specific details come out about nation state programs using malware, there has been more anger from the targets. While this anger would be valuable if it was directed towards auditing algorithms and software to look for manipulation, it is instead appearing to fracture the universality of the Internet instead.

While new systems may be good, working to improve universal standards may be better. For several years there has been questions about National Institute of Standards and Technology’s (NIST) SP 800-90 for elliptical curve cryptography. The fundamentals of the math are not in question, only the implementation details. Unfortunately, governments will attempt to continue to influence these implementations, as anyone with their power would do as rational actors attempting to increase their own power.

And that is the main lesson of government use of malware. It is functionally not very different from anything from the last few decades. Phone companies have been required to allow interception by legitimate requests for over a century, and espionage has a history dating back millennia. Perhaps the scale is different, but policy solutions have been shown to inevitably fail. Technical solutions are possible, but require a great deal of work and are far from certain to work.