1) Privacy is free. Many privacy advocates believe it is a free lunch‚ - that is, consumers can obtain more privacy without giving up anything. Not so. There is a strong trade-off between privacy and information: The more privacy consumers have, the less information is available for use in the economy. Since information helps markets work better, the cost of privacy is less efficient markets.
There are two problems with this statement. The first counter-fallacy is the idea that more information, any information, makes markets work better; that just isn't true. Take a simplistic example of someone who signs up for a golf magazine and is then spammed by so many adverts for golfing gear that they train their spam filter to block it. The company got some information, used it inappropriately, leading to the client making fewer purchases for no better reason than too much advertising. What's needed is a mechanism for the right (i.e. necessary to enable consented activities in the consumers interest) information to get to the right companies (i.e. not spammy affiliates or surveillance groups). This is exactly what privacy advocates are working for currently; what controls can enforce this rather than the overly permissive current state.
The second problem is that the cost goes both ways. Right now a consumer has to spend the effort in enforcing their privacy. The current technical complexities of, for example, ensuring cookies for services you use, are not used to correlate your identity across affiliate sites, is high and only performed by the few who understand the implications and care enough to do something about it. Thus, the cost (understanding, technical ability, actual work required) is too high for many consumers to reasonably enforce their own privacy. This cost needs to shift to companies in order to achieve a more reasonable middle ground.
2) If there are costs of privacy, they are borne by companies. Many who do admit that privacy regulations restricting the use of information about consumers have costs believe they are born entirely by firms. Yet consumers get tremendous benefits from the use of information.
Think of all the free stuff on the Web: newspapers, search engines, stock prices, sports scores, maps and much more. Google alone lists more than 50 free services‚ - all ultimately funded by targeted advertising based on the use of information. If revenues from advertising are reduced or if costs increase, then fewer such services will be provided.
I don't see fewer services, in return for more control of what information is collected and how it is used, as a poor trade off i.e. it's a cost most consumers would be willing to bear. If anything, efficiencies may be generated in the market with weaker services that exist purely as third party data collection points (e.g. spammers, personal data warehouses (e.g. Axciom) and other organisations that end up with data from our primary service providers that we would prefer didn't) being weeded out. It would be hard to argue that more privacy would result in all information supported services disappearing.
Giving consumers more control of their information does not lead to firms having worse information. If anything the firms are likely to have access to higher quality information and avoid many of the poor inferences current data sets lead to (e.g. googling for "bomb making" means you're a terrorist). The key quality differentiator is that a consumer can target the intended use with the right information, due to the disclosure of intended use by the firm when gathering consent. The current situation is more akin to my bank knowing my shoe size, just because they can, and sharing that with affiliates; rather than the bank collecting credit rating specific data for their own calculations.3) If consumers have less control over information, then firms must gain and consumers must lose. When firms have better information, they can target advertising better to consumers‚ - who thereby get better and more useful information more quickly. Likewise, when information is used for other purposes‚ - for example, in credit rating‚ - then the cost of credit for all consumers will decrease.
4) Information use is "all or nothing." Many say that firms such as Google will continue to provide services even if their use of information is curtailed. This is sometimes true, but the services will be lower-quality and less valuable to consumers as information use is more restricted.
For example, search engines can better target searches if they know what searchers are looking for. (Google's "Did you mean . . ." to correct typos is a familiar example.) Keeping a past history of searches provides exactly this information. Shorter retained search histories mean less effective targeting.
Once again, we have the counter fallacy: "more information == higher quality service" coupled with a misunderstanding of what sort of control privacy advocates are looking for.
First, a large amount of information currently collected is not collected for direct use with that service; while Google search does collect your search term, it also correlates that use with other services. If Google were to say "we collect exactly this information for this specific purpose, if you don't like it leave" that would be a huge improvement over the current vague statement of "we collect some information, we share some of it, if you don't like it leave, but we'll still try to track you around the web."
Second, privacy advocates, for the most part, have no problem with Google collecting search terms and using that data for the typo correction example above. The problem is strongly associating those terms with an identity and then barely anonymising them. It would be quite possible for Google to collect the search terms and provide typo correction without knowing UserX searched for that term.
5) If consumers have less privacy, then someone will know things about them that they may want to keep secret. Most information is used anonymously. To the extent that things are "known" about consumers, they are known by computers. This notion is counterintuitive; we are not used to the concept that something can be known and at the same time no person knows it. But this is true of much online information.
This "fallacy" is phrased incorrectly. It should be "If consumers have less privacy, then someone *could* know things about them they may want to keep secret." This is not a fallacy. Sure, for the most part there isn't a sweaty sysadmin reading each of my Yahoo mails (although research by others suggests there may be), but if a sysadmin/private investigator/government organisation wanted to they could. If the information is stored and identified then at some point someone will want to consume it. My experience in information security tells me that you can't provide perfect protection, and as the Saudi/RIM lawful intercept saga indicates, gov pressure to be able to violate your privacy/secrecy/confidentiality wins. As the Google/China hack indicates, lawful intercept gets used by the bad guys too.
What's more, the advanced data analytics performed by the likes of Facebook and Google allow additional secret information, that you may not have intentionally disclosed about you, to be discerned. In short, if the information isn't stored, it can't be compromised.
It may be because I'm not an economist but it sounds like Rubin makes a weak point (coupled with my observation in parenthesis) here: "Differential pricing is bad (mostly to the poor), but some good could come from it (mostly to the rich), so it's okay." The way I see it, if one side has perfect information about the other, but not vice versa, then the negotiation is flawed and will not work to mutal benefit. Even if you could argue that this is not true, people who take steps to prevent their information from being collected and tagged with their identity would be in a stronger bargaining position and would benefit more than the consumers who didn't.6) Information can be used for price discrimination (differential pricing), which will harm consumers. For example, it might be possible to use a history of past purchases to tell which consumers might place a higher value on a particular good. The welfare implications of discriminatory pricing in general are ambiguous. But if price discrimination makes it possible for firms to provide goods and services that would otherwise not be available (which is common for virtual goods and services such as software, including cell phone apps) then consumers unambiguously benefit.
It's true, harm from privacy violations is difficult to asses. If only someone wrote a book about it providing some sort of comprehensive taxonomy of privacy harms. In short, it is very short sighted of Rubin to claim that violations of online privacy cannot lead to harm.7) If consumers knew how information about them was being used, they would be irate. When something (such as tainted food) actually harms consumers, they learn about the sources of the harm. But in spite of warnings by privacy advocates, consumers don't bother to learn about information use on the Web precisely because there is no harm from the way it is used.
The panopticon is a well understood and flawed model. Giving firms and governments all the information reduces consumer liberty and gives firms/governments all the power. There needs to be a balance; banks can't have "anonymous" banking with them, and governments can't allow "anonymous" through their borders. However, governments shouldn't be able to ask banks about all their customers because they feel like create some sort of creepy total awareness office. If anything allowing consumers more control over their information and firms/governments less control makes it easier for consumers to keep those firms/governments honest leading to a more efficient market.8) Increasing privacy leads to greater safety and less risk. The opposite is true. Firms can use information to verify identity and reduce Internet crime and identity theft. Think of being called by a credit-card provider and asked a series of questions when using your card in an unfamiliar location, such as on a vacation. If this information is not available, then less verification can occur and risk may actually increase.
I'm calling wild assertion on this one. While the mass of information gathered is likely used for benign purposes, the exceptions which cause harm and the potential for this harm to occur if no controls are in place, is enough to justify their existence. That's why even though the majority of the populace don't commit crimes, we still have police for the few who do.9) Restricting the use of information (such as by mandating consumer "opt-in") will benefit consumers. In fact, since the use of information is generally benign and valuable, policies that lead to less information being used are generally harmful.
10) Targeted advertising leads people to buy stuff they don't want or need. This belief is inconsistent with the basis of a market economy. A market economy exists because buyers and sellers both benefit from voluntary transactions. If this were not true, then a planned economy would be more efficient‚ - and we have all seen how that works.
If Communism is to economists as Nazism is to moralists, then I'm calling Godwins Law (I know, I lose). That being said, I'm not going to defend this point, as it's a dumb one. Targeted advertising is much better than untargeted advertising. Guess what's better for the consumer? NO ADVERTISING coupled with easy ways of finding out information on products they actually want to purchase. The only reason I allow advertising (and sometimes click the ads) is for sites I want to support who use ad-revenue, for the rest, there's ad block. But I try not to let any of them profile me to offer targeted ads, yet somehow I am still fully empowered to both find products I want, research them in detail and purchase them from companies selling them.
This brings us to the end. In short, I disagree with everything Rubin says. He misunderstands that privacy advocates are looking for a balance of controls, not extremes, and makes unvalidated assertions about how information inherently leads to all sorts of good economic things. He also fails to consider abuses of information, which are the specific cases privacy advocates are trying to protect against.
This is a cross-post from my other blogging home at SensePost.
Last week we presented an invited talk at the ISSA conference on the topic of online privacy (embedded below, click through to SlideShare for the original PDF.)
The talk is an introductory overview of Privacy from a Security perspective and was prompted by discussions between security & privacy people along the line of "Isn't Privacy just directed Security? Privacy is to private info what PCI is to card info?" It was further prompted by discussion with Joe the Plumber along the lines of "Privacy is dead!"
The talk, is unfortunately best delivered as a talk, and not as standalone slides, so here's some commentary:
We start off the problem statement describing why privacy has grown in importance. The initial reactions were based on new technology allowing new types of information to be captured and disseminated. While the example given is from the 1980s, the reaction is a recurring one, as we've seen with each release of new tech (some examples: Cameras, Newspapers, Credit Cards, The Internet, Facebook). Reactions are worsened by the existence of actors with the funding & gall to collect and collate much information to further potentially disagreeable goals (usually Governments). However, the new threat is that there has been a fundamental shift in the way in which we live our lives, where information about us is no longer merely *recorded* online, but rather, our lives are *lived* on line. It is quite possible that for an average day, from waking up to going to sleep, a significant number of the actions you perform will not only be conducted (in part) online, but that it is possible for them to be conducted using the services of one service provider. My intention is not to beat up on Google, but rather use them as an example. They are a pertinent example, as every business book seems to use them as one. The, arguably, most successful corporation of our current age's primary business model is the collection & monetisation of private data. Thus, while Google is the example, there are and will be many followers.
The next section moves into providing a definition of privacy, and attempts to fly through some fairly dry aspects of philosophy, law & psychology. We've done some entry-level work on collating the conception of privacy across history and these fields, however, brighter minds, such as Daniel Solove and Kamil Reddy have done better jobs of this. In particular, Solove's paper "I've got nothing to hide", and other misconception of privacy is a good introductory read. The key derived point however, is that private data is data with an implied access control & authorised use. Which of the implied access controls & authorised uses are reasonable to enforce or can be legally enforced is a developing field.
As the talk is about "Online Privacy" the talk moves into a description of the various levels at which private data is collected, what mechanisms are used to attempt to collect that data, and what sort of data can be gleaned. It was an academic conference, so I threw in the word "taxonomy." Soon, it will be more frequently quoted than Maslow's Hierarchy, any day now.
At each level, a brief demonstration of non-obvious leaks and their implications was demonstrated. From simple techniques such as cross-site tracking using tracking pixels or cookies, to exploit of rich browser environments such as the simple CSS history hack, to less structured and less obvious leaks such as search data (as demonstrated by the AOL leak), moving to deanonymisation of an individual by correlating public data sets (using the awesome Maltego) and finally to unintended leaks provided by meta-data (through analysis of twitter & facebook friends groups).
Finally, a mere two slides are used to explain some of the implications and defenses. These are incomplete and are the current area of research I'm engaged in.
Online Privacy, the next BattlegroundThis week something special happened, something I'd been saving for the right person, something magical. Today, hackers took my private data. Everything's changed, I feel like a part of the world, connected to so many other people who have shared in this experience. Today, I'm a woman! (Ok, I may have gone a bit far with that last bit)
The skinny is that I use unique e-mail addresses for each service provider that I want to continue communicating with (for the ones I don't I use one-shot addresses). I noticed on the weekend that I was being deluged with pharmaceutical spam to three of these addresses, namely my Threadsy, Numbuzz & Share-it (via a product I bought there, ChatterBlocker) contacts. This lead me to tweet: "Either a security or ethics breach at @threadsy & @nimbuzz Getting Viagra spammed hard on the unique e-mail addresses I gave them."
Chatterblocker got back to me with the equivalent of "What? Wasn't me." Scott Kendall from Threadsy jumped into an investigation however and contacted me for more details. He also passed on results of his investigation to Nimbuzz, much kudos. Scott then informed me this morning that there has been a breach at iContact, evidently a shared service provider to the affected entities, resulting in the theft of customer contact details that must have been sold to spammers (or by a horizontally integrated crime crew). We're assured by iContact that only our e-mail addresses were stolen. However, we're not given any reason to believe that; unless the data is segmented somehow I don't see why an attacker wouldn't take the whole caboodle.
What concerns me is first that I wasn't even aware I had a relationship with iContact. A quick look of the websites of Threadsy and Nimbuzz don't make reference to them apart from the generic "we may share your data with business relevant third parties" in the privacy policy. Even if it is made explicit in the privacy policy, it doesn't mean you understand it, take this Facebook friendlist leak for example. Maybe if we had a "nutritional label for privacy" with disclosure of who the third parties were I would feel more in control of my data and more importantly the decisions I make.
Second, I'm not aware what data of mine had been given to iContact and what could potentially be at risk. Was it just my contact details, or did it include behavioural data too? Even if I can't do anything about it, I'd like to know what was breached with some solid factual basis. More importantly, I'd like to see what is shared with the third-party up front. I believe the small externality of writing that down in human readable and explicit form may encourage service providers to limit it.
Third, this was a consumer-lead breach-discovery. People with custom e-mail addresses tracked the source and informed iContact they had a breach. We see the same thing with credit card breaches, and with the likes of Google notifying other companies that the APT (do I get points for using it?) got them too. Is it any wonder those are the breaches we see frequently reported. IT shops usually aren't aware they've been breached until an affected third party tells them.
In conclusion, if you're getting spammed hard with pharmaceutical spam, this is probably why. There's nothing you can do about it, and there's probably a near infinite number of variations of your private (by which I mean data you don't want publicly exposed) data floating around at service providers you know nothing about that doesn't have the same canary-in-a-mine like properties that can make you (and hence the service provider) aware of the breach. Good luck.
As a precursor to this, I did some playing and realised (later than most it seems) that the GoogleSharing proxy implements a straight HTTP 1.1 proxy. A few quick lines of code, thanks to some help from Andrew Mohawk due to some gzip'ed return data trouble, and you have a very simple PHP interface to GoogleSharing:
<?php
ini_set("user_agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)");
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,"http://www.google.com/custom?q=" . urlencode($_REQUEST['q']));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_PROXY, "http://proxy.googlesharing.net");
curl_setopt($ch, CURLOPT_PROXYPORT, 80);
curl_setopt($ch, CURLOPT_ENCODING , "gzip");
$x = curl_exec($ch);
print $x;
curl_close($ch);
die();
?>
My only worry is that I've been down this road before, 5 years ago, and I want things to happen a little differently this time. What happened then is thousands of porn sites hosting malware decided that privacy enhanced search was just what their customers needed. This resulted in Google seeing several hundred malware infested links linking back to this site. The net result was that I dropped out of Google completely (with no warning or explanation of course). So my intention is not that you use my search interface. That's stupid anyway as you have no reason to trust that I'm not mining your search data. So here is a tarball that can be used to set up your own PHP front-end. You'll need a PHP-enabled webserver with curl. The readme has more.
July 1,
2010: Here we go again...
We regret to announce that our Google scraper may have to be
permanently retired, thanks to a change at Google. It depends on whether
Google is willing to restore the simple interface that we've been
scraping
since Scroogle started five years ago. Actually, we've been using that
interface for scraping since Google-Watch.org began in 2002.
This interface (here's a sample
from years ago) was
remarkably stable all that time. During those eight years there were
only
about five changes that required some programming adjustments. Also,
this
interface was available at every Google data center in exactly the same
form, which allowed us to use 700 IP addresses for Google.
That interface was at www.google.com/ie
but on May 10, 2010 they took it down and inserted a redirect to
/toolbar/ie8/sidebar.html.
It used to have a search box, and the results it showed were generic
during that entire time. It didn't show the snippets unless you
moused-over the links it produced (they were there for our program, so
that was okay), and it has never had any ads. Our impression was that
these results were from Google's basic algorithms, and that extra
features
and ads were added on top of these generic results. Three years ago
Google
launched "Universal Search," which meant that they added results from
other Google services on their pages. But this simple interface we were
using was not affected at all.
It is not possible to continue Scroogle unless we have a simple
interface
that is stable. Google's main consumer-oriented interface that they want
everyone to use is too complex, too bloated, and changes too frequently,
to make our scraping operation possible.
After a lot of suggestions from Scroogle users, and a fair amount of
publicity, we found a fix and Scroogle was back in 24 hours. This fix
was
to insert an extra parameter, &output=ie, into the search terms that
were
relayed to Google. The extra parameter recovered the same interface that
we thought was gone forever.
Now it seems like it actually might be gone forever. Late on June 30,
2010,
the results produced while using this parameter began to shift to the
usual
busy Google interface with ads and a left-margin sidebar. Scroogle users
saw a Scroogle page that said, "Google returned no results for this
search," when in fact Google returned results but our scraper was unable
to deal with them. Over the next few days we will attempt to contact
Google and determine whether the old interface is gone as a matter of
policy at Google, or if they simply have it hidden somewhere and will
tell
us where it is so that we can continue to use it.
Thank you for your support during these past five years. Check back in a
week or so; if we don't hear from Google by next week, I think we can
all
assume that Google would rather have no Scroogle, and no privacy for
searchers.
— Daniel Brandt, Public Information Research, scroogle AT lavabit.com
This problem was mostly easy to solve by blocking third-party cookies, i.e. cookies for domains other than the page you are on. Things got a bit self-moderating too when the Network Advertising Initiative's members decided to push for tracking opt-out. This spawned tools like the Targeted Advertising Cookie Opt-Out which let's you opt-out of all the advertisers you can (currently at 90). There's problems with both of those options, but they at least provide mostly n00b-proof privacy. For the slightly less n00by Firefox add-ons like CookieSafe provide default-deny with one-click enable capabilities to drastically reduce the number of cookies you find in your jar.
The problem came in with providers who try and rule the world, while providing services I want to use. The most obvious of these is Google. When I first started using Gmail, I realised that Google forced you to accept a cookie from google.com to use the service, and you couldn't just accept cookies for mail.google.com. What's more, Google's code, either in the form of AdWords or Analytics is embedded on most of the internet, and I use several of their other services like Search & YouTube. This means that I have to accept their root, long expiring cookie and have my browser regularly send it to Google associated to my Google account identifying nearly every page I'm on.
My solution to this problem was previous in two parts. The first was to make sure than any "logged on" interactions I had with Google were in a separate Firefox profile. This ensures that the necessary google.com cookie set there would be isolated from my usual surfing. The second part was to limit my direct use of Google services. This lead me to Scroogle, a privacy enhancing Google scraper; and GoogleSharing.net, Moxie's identity randomizer for Google services. That meant that I could happily never have a google.com cookie set in my main browser, except in a isolated Firefox profile.
However, recently, the next challenge for the internet has created a new problem, Facebook. Facebook's recent salvo to rule the internet has lead to a plethora of sites embedding Facebook scripts in their pages for their like buttons. This means I am faced with the same problem as Google, a site I regularly log-in to, which sets a cookie strongly associated to my identity, and is regularly sent to the provider as I surf the internet. Initially, I just added Facebook to my isolated Firefox profile. However, this is where I discovered Stainless.app
Stainless.app is a very simple web-browser build off WebKit. Their key feature, is that they take Google's Chrome browser's per-tab process+sandbox a bit further providing per-tab sessions. What this means is that each tab (or sub-tabs you choose to spawn from it) is a self-contained session, and a cookie for google.com or facebook.com set in the one tab, would not be available to the next tab. This provides a per-default session isolation, preventing cookies from existing across a browser session, and not just cookies, sessions. Thus, if I were to log in to Facebook and have a cookie set for facebook.com, navigating to memeburn's website will mean the included "like" button's script won't be able to query that cookie, and will set a whole new one.
What's more, is that this buys you some security too, and has the potential to kill authenticated CSRF as an attack vector (by itself, but "please log in" style CSRF's would still work), because the tab you open up the CSRF attack in, wouldn't have access to your logged in session in another tab.
To enable this, you will need to install Stainless.app (OSX currently), then set Preferences -> Security -> "Create new single session tabs by default", and restart the browser.
Unfortunately, in using Stainless, I loose the ability to block third-party cookies entirely (they are still set, just per tab), the ability to block ads with AdBlock Plus and the extra security afforded by NoScript. The first isn't a big problem, given the built in isolation, the second can be somewhat recreated with Squid(or SquidMan for OSX)+SquidGuardian+Easylist, and the third, we'll just have to wait.
In short, this means I can consolidate into one default browser profile for by usual browsing, but I'll still need Firefox for anything else.
Ritasha Jethva, our Privacy & Data Protection competency lead added some nice tips to a publicity piece that made it otherwise more useful than it would have been. I'm republishing them here along with some other stuff I've found of late.
You may already be a victim of identity theft if:
- Items have appeared on your bank or credit-card statements that you do not recognise.
- You've applied for medical or other benefits but are told that you are already claiming.
- You've received bills, invoices or receipts addressed to you for goods or services you never purchased.
- You've been refused a credit card or loan, despite having a good credit history.
- A mobile-phone contract has been set up in your name without your consent.
- You have received letters from lawyers or financial institutions for debts that aren't yours.
- Mail expected from key organisations the likes of your bank have not arrived, or even if you are not receiving any mail correspondence at all.
The following tips will help you protect your identity and prevent criminals from committing fraud in your name:
- Turn off extra features in any technology that you aren't using.
- Always think before you click or press a button; personal awareness is key.
- Don't throw away entire bills, receipts, credit-or debit-card slips, bank statements or even unwanted post in your name. If you do need to destroy unwanted documentation, do so using a shredder if possible.
- Keep your personal documents in a safe place, such as a lockable drawer or cabinet.
- Be vigilant around what you publish about yourself, especially on internet sites.
- If your passport, ID book or drivers licence has been lost or stolen contact the issuing organisation immediately.
- Keep your passwords safe and never record or store them in a manner which leaves them open to theft, such as in your purse or wallet.
- Check statements as soon as they arrive. If any unfamiliar transactions are listed, contact the company concerned immediately.
- Never divulge personal information via email or sms' no matter how trustworthy the request may appear to be
Then, to add some stuff I've picked up (mostly from a technical level) that has worked well:
More advanced users like to know what is nailing their CPU, and have some form of hotkey of screen widget nearby to tell them. But sometimes it takes too much effort for the computer to show you this application while it's thrashing away and I've been looking for a nice unobtrusive on-screen "gadget" that gives me all the information I need. After going through hundreds of windows sidebar gadgets, Mac widgets and now Gnome screenlets, I've hit on a winning strategy (for Linux, but the concept remains the same).
I'm using a semi-transparent Output screenlet to display the contents of the following command in Linux, and GeekTool to do the same on OSX:
GNU/Linux: top -b -n1 -s -i | head -n9 | tail -n3 | grep -v " top " | cut -b1-16,42-50,61-80
BSD: top -R -u -i100 -l2 -ncols 3 | grep PID -A5 | tail -n6
People often forget that disk IO is also an important indicator. Sometimes your CPU usage is moderate but your computer is frozen while your disk thrashes away. So I have a second screenlet with the output of (I don't have one for OSX yet):
iotop -n1 -b -o | grep -v "Total DISK READ:" | cut -b1-38,55-80
What does this buy me? Well, with a quick glance I can find out what process is currently killing my CPU or disk. It also includes the PID for quick "kill" or "renice" access (transparent terminals make reading the PID easy). Additionally, in a few weeks, it has given me a far greater understanding of how applications on my computer work and interact with others. For example, Crossover Office (aka wine) makes Xorg flatline a CPU core when it starts a new wineserver (I blame compiz funkiness). I don't actually care about that, what I do care about is I now know how and when to expect delays when starting crossover apps. The end result of this overcomplicated explanation is that the frustration of using a computer has significantly decreased now that I know what to expect.
Also, when I invariable break something, these strings will be here for me to copy paste back into existence.
The ZaCon II CFP is nearing it's closure date (tomorrow!), and this is an overt reminder to all of you thinking about submitting to do it. ZaCon is a great place to either give your first infosec presentation or deliver a tech-heavy presentation to a receptive crowd. All you need do is submit a short abstract to abstracts@zacon.org.za and if your submission is accepted, prepare and deliver a presentation. You don't even need to write a paper. If that isn't lowering the barrier to entry enough, then you're just lazy :)
If my submission is accepted (heavy bribery underway), then I'm hoping to set up an infosec BP-style debate, and will be approaching some of you "I'm smart but never share that outside the office" types to get involved, and hopefully have some fun.
You can read more of my thoughts on ZaCon here. Also, at some indeterminate point in the future, some ramblings about ZaCon will appear in episode 18 of Let's Talk Geek.
ifconfig -u|grep -v inet6|grep -v media| grep -v lladdr|grep -v ether|grep -v status|sed "s/flags=.*//"|sed "s/^.*inet \(.*\) netmask.*$/\1/"|sed "s/^\([elfv]\)/#\1/"|tr -d '\n'|tr '#' '\n' && echo
I just want a simple display of the interfaces on my system and their IPs. I was in a rush and came up with that disgusting line. On the one hand it demonstrates the power of Unix, on the other hand it demonstrates the problems with it. So, dear interwebs, please provide me with (in order of preference):
Failing that, here's a command you too can use to give you a fragile list of interfaces and their ipv4 addresses. I've embedded it on my desktop with GeekTool (OSX). It makes the FW logs also embedded on my desktop make more sense :)
UPDATE: I love you my fellow Geeks. The winning solution is from Craig Balding via twitter, who put us all to shame with the ridiculously simple piece of cli kung-fu that is:
ifconfig|awk '/mtu/ {nic=$1} /inet / {print nic " " $2}'
Doug Burks who initially
came
up with both the shortest, easiest to read & least fragile solution
with a combination of (1) & (2). However, it was noticeably slower
than the others due to awk. At only 2chars longer, but faster, my
modification of his is:
for i in `ifconfig -lu`; do echo -n $i:\ ; ifconfig $i |grep inet\ |grep -o "[1-9][^ ]* " | tr -d '\n'; echo; done
Rogan Dawes who greatly optimised ala (3) (with some ugliness from mine to make the tuples take one line):
ifconfig -u | egrep "^[a-z]|inet " | sed -e "s/ flags.*$//" -e"s/^.*inet \(.*\) netmask.*$/ \1/"|sed "s/^\([elfv]\)/#\1/"|tr -d '\n'|tr '#' '\n'&& echo
Haroon Meer who aimed for (1)
using OSX's networksetup. However, networksetup doesn't list all
interfaces (e.g. the vmware interfaces). Also, combing the output to one
line per tuple is a pain.
This has been reposted from it's original at my new second blogging home at SensePost.
In my previous role working as a security manager for a large retailer, I developed some password tools for various purposes, primarily to help non-security people with some of the basics. I licensed them under the GPL, and I think it's about time they saw the light of day.
There are a couple of tools, which I will explain below. They're all written in JavaScript, primarily because it is cross-platform, but can be centrally hosted. They all work in Firefox and Internet Explorer, although the automatic copy to clipboard functionality of the service desk tool is IE only.
The intention is for the tools to be placed into your organisation's intranet somewhere. I found they came in much use, allowing me to reference a specific tool and setting rather than esoteric password theory in documents. For example, security standards documents would say "Service account passwords should either be generated by the password generator set to the service account setting, or be rated as "very strong" by the password strength checker", which is far more practical than quoting a list of password rules.
Being centrally hosted also allows updates to be made immediately in the case of a policy change, new common password addition, or bug. This also allowed web logs to provide an audit trail of who was using the tools. Particularly useful in the case of monitoring service desk activity e.g. If the service desk records 100 password resets, and the tool only saw 10 hits, you know something's up.
If you're a tactile learner, you can grab them here.
This tool was written in response to the poor attempts at password strength checkers seen on many sites. They do basic checks for upper, lower-case characters and numbers. This allows passwords like "Password1" to be marked as "strong." Primarily based on Tyler Atkins' entropy and common word checker, I put together a more advanced utility. This will check the chosen password for:
There are two versions provided, one which displays the results of the entropy calculations, and one which does not (user's rarely care).
There are three password generators, each with a different audience in mind.
The full password generator is the most complex and has a number of features:
The service desk password generators were created to help the service desk stop resetting everyone's password to the same thing. It's one of the most pervasive security problems in any organisation, the service desk are told to reset passwords to some common password like "abc123", "Password<x>" or "<username>". Most user's know it, and if you do ever investigate service desk password resets, will find some serious abuses going on. This tool is a quick and dirty way to provide more reasonable alternatives for the service desk to use.
It's basic features are:
These tools where originally written when I was an employee of
Deloitte South Africa, and while necessarily under the GPL due to
included code, are still published here with permission of them. They
have however, been updated since then on SensePost's coin.
Verizon's Wade Baker (with assistance from Dave Kennedy, who I will refer interchangeably to as with Wade, Dave or Verizon) published a post claiming that vulnerability/security researchers are given too much leeway, and are closer to criminals than good guys. He suggests they should rather be called "narcissistic vulnerability pimps" (NVPs) in future. Dan Goodin got some clarification when writing his piece for The Register which expands on some of Verizon's motivations and justifications.
While I think I identify with part of his frustrations, he's wrong. Mostly due to an overconfidence in how vendors optimise for "shareholder value", but also because while scrabbling to paint vuln researchers as bad guys, he forgot about the actual bad guys.
Wade suggests three categories that could be used to describe security professionals, as they are neither exclusive, accurate or sufficient I'm going to ignore them. Instead, I'm going to try and distill what Wade believes is the problem, and his preferred approach while attempting to avoid the straw man.
Wade seems to believe that people who discover vulnerabilities, then publish them to the general public, whether after informing the vendor or not, are motivated predominantly by glory and not good intentions. The few motivated by good intentions, it seems, would also be labeled problematic by Wade (& Dave, as the quote is his) because:
[F]ull disclosure was never a good idea, even in cases, like Ormandy's dust-up with Oracle.
The alternative it seems Verizon would like to see, is that researchers who find vulnerabilities report them to the vendor and walk away. I'm assuming they'd allow for some follow up, but publishing the vulnerability publicly would earn you the NVP label. Once again a quote from Wade/Dave/Verizon/Dan Gooding:
"Apple has a responsibility to their shareholders and to their customers to deal with the vulnerabilities, and their shareholders and their customers can hold Apple's feet to the fire. They have their own ways of exerting pressure on Apple to behave in a way they think Apple should behave."
There's an obvious problem with Wade's approach; it isn't universalisable, and we have hard facts for that. There are many vendors who don't act on reported vulnerabilities as anyone who's ever submitted security flaws to vendors can tell you. David Litchfield has even waited a few years before eventually publishing Oracle vulns. Even if every vendor in existence responded to discovered flaws perfectly, there's no obligation for them to. If we look at the externalities pressuring them to action, sexy new features are going to please both shareholder and customers more. Those same customers and shareholders don't really understand this complex security mumbo jumbo, and so in the rare instances when they can patch a bug without at least one news outlet publishing a "OMFG there's a flaw in product X" the customers and shareholders still aren't going to fully appreciate the security fix. What's more, if a security fix prevents a customer from getting hacked, they will have no idea, and won't credit the vendor. The only time not deploying a fix will be a problem for the company is if a mass or high-profile public hack of their customers occurs. Given that most criminals don't like getting caught and that computer crime is hard to detect, that's a much rarer event than the actual occurrence of hacks. This is exactly why full disclosure came about, *in response* to the way vendors were ignoring bugs, to add another externality to drive them into fixing bugs.
This is where the difference between actual computer criminals and security researchers becomes important. Something Wade get's woefully wrong:
Have you ever heard of a terrorist referred to as a “demolition engineer?” How about a thief as a “locksmith?” No? Well, that’s because most fields don’t share the InfoSec industry’s ridiculous yet long-standing inability to distinguish the good guys from the bad guys.
The security researchers Wade is taking aim at are the one's who publish their work publicly (hence the addition of "narcissistic" I believe). But there are a whole whack of people who don't publish their work publicly, or to the vendor or even via vuln clearing houses like VDI (which eventually gets to the vendor). Wade doesn't pass judgment on them. Even those people aren't criminals. One could argue they aren't optimising for the public good, because an actual criminal could have found the same flaw and be privately exploiting it. They aren't criminals because they haven't committed a crime, or even harmed anyone. Actual criminals are people who either discover or buy flaws and then use them to (or have the intention to) commit a crime. This is the distinguishing difference between a thief and a locksmith, or a terrorist (an already loaded term) and a physical pentester. Their intention, and what they do with the information. One uses it to fix the hole, the other exploits it. This is why full disclosure exists, not the make money, but to encourage people to fix the holes, not exploit them. The fact that it can buy you a limited about of fame is a bonus because it provides an incentive to go public (one that pales in comparison to the hard dollars you can get via other means).
Finally, I do identify with parts of Wade's frustration with regards to people who either disclose without reporting to the vendor first, or hype a vulnerability way beyond it's actual risk. The first leaves the install base vulnerable with the exploit popularised, the second causes people to optimise resources poorly. There's room for updated research on vulnerability life cycles, to ensure the debate revolves around facts and not hypothesis. Either way, one should not be confused about which side those researchers are on. They are the good guys, their work could be used in far more evil ways, they do work the vendor isn't able/capable of. They make us safer, maybe not always in the best way, but in the end they make us safer.
Today my blog turned six, and I tweeted that fact with the following:
My blog http://singe.za.net/ turned 6 today. The fact that I'm tweeting this rather than blogging it is probably significant.
While blogging remains more a more satisfying and useful means of exploring a thought, twitter let's you skip the work and move onto the conversation (sometimes) a bit sooner, but without any decent record of that conversation occurring (twitter's searchable memory is too short). I'm certainly going to continue blogging, but I don't see my throughput increasing much. Luckily, subscribing to an RSS feed is only a cost if there are too many updates ;).
That being said, I think there's been some fun stuff on the blog in the last year, my favourite posts have been:
In short, it's been awesome. I haven't done much real work as yet, but that will start soon. The people are smart and easy to get along with, and they're all geeks, a nice change (on the geeks bit, my old colleagues are smart too :) ). I'm also enjoying getting to know "how they roll" and recon living up to it will make me a better security person.
As an aside, my new work e-mail address is available here (or sans popup).
For the week of 7-14 April
2010, we undertake to talk about this country, its challenges, its
promise, its news, and to ignore Julius while doing so. Join us in this
initiative. If you blog, join the roll. If you Tweet, add the hashtag
#ignoreJulius to your daily output.
However you communicate, take a week off from Julius.
Here is the list of blogs that are participating in this initiative: http://rwrant.co.za
http://zoem.co.za
http://www.thoughtleader.co.za/mariusredelinghuys
http://memyselfandkarin.wordpress.com/
http://robsramblings.co.za
http://antithesis.blognation.co.za/
http://singe.za.net/
http://blog.empyrean.co.za
http://www.pinkhairgirl.co.za
http://www.macgeek.co.za
http://www.futurechurch.co.za
http://www.cptawesome.co.za/
http://www.indigogirl.co.za/
Thanks to Jason van Niekerk for writing the above text, and Henno Kruger for suggesting and running with the blog initiative.
Ignore Him at Your Peril - I'm not suggesting we ignore him permanently, or ignore the political youth or the ANC YL. I'm hoping this will restore some balance so that we have less Heat-magazine-like reporting on Julius resulting in more balanced, less obsessive coverage of relevant political activities.