Vær snill med roboten?

Som noen kanskje har fått med seg har politiet tatt ut tiltale mot to personer for å ha lurt en robot. Den uheldige roboten eies av det utenlandske meglerhuset Timber Hill. Roboten ble visstnok lurt 2200 ganger og var således ikke av den mest lærenemme varianten.

Saken er helt spesiell siden det normalt er roboten som er kjeltringen i finansmarkedene. Det har lenge vært kjent at meglerhus flytter sine datamaskiner fysisk nærmere børsen slik at signalene skal bruke kortest mulig tid fra børsen til meglerhusets server. En del børser har til og med latt finansinstitusjoner ha servere inne i selve børsbygningen. En daytrader er derfor normalt sjanseløs mot slike lynkjappe roboter, som har blitt beskyldt for alt fra juks til å forårsake unormalt store svingninger i aksjemarkedet.

Så hvorfor er myndighetene da så ivrige etter å ta to amatørinvestorer for å ha lurt en slik robot. Dette er tross alt en klassisk david-mot-goliat-historie hvor David vinner til slutt.

Jo, akkurat denne roboten hadde trolig fått tildelt en helt spesiell rolle i markedet som ”market maker”, og det går for å være nokså gjevt i robotmiljøet. Market makerens oppgave er å tilby kjøps og salgskurser for små og lite likvide aksjer. For enkelte verdipapirer er en slik aktør helt avgjørende for at det i de i det hele tatt skal eksistere et marked. Oslo Børs ber derfor av og til meglerhus om å passe på enkelte aksjer med spesielt lav omsetning ved å påta seg denne oppgaven. Meglerhuset forplikter seg da til å holde differansen mellom kjøps og salgskurs innenfor et gitt nivå. For den vanlige investor betyr det at en enkelt kan få omsatt aksjene en sitter på, noe som reduserer risikoen betydelig. Meglerhusene bruker automatiske handelssystemer til dette, eller roboter, og tjener på sin side på at kursene han kjøper til jevnt over er lavere enn de han selger til.

Det er imidlertid helt avgjørende at roboten endrer kjøps og salgskursene kontinuerlig i takt med ordretilgangen. Hvis ikke vil eksempelvis en økning i tilbudet føre til en stadig større beholdning av aksjer og en tilhørende økning i den finansielle risikoen. Roboten i denne aktuelle saken har fulgt den meget enkle regelen at kursen justeres opp hver gang noen kjøper aksjer.

Denne enkle strategien kan utnyttes. En kjøper et større antall aksjer til gjeldende salgskurs. Deretter ”dytter” man robotens kjøps- og salgskurser oppover ved å kjøpe små ubetydelige kvanta til økende pris. Når kjøpskursen er høyere enn den opprinnelige salgskursen, selger man alle aksjene.

Bør så dette være ulovlig? Oslo Børs vil hevde at dersom det skal være lov å manipulere tynne markedet på denne måten, så vil de små selskapene forsvinne ut av børsen. På den annen side så har ikke denne roboten vært spesielt oppvakt. De som har programmert roboten må ha vist om denne sårbarheten, så det er jo litt rart at man ikke har laget en sikkerhetsmekanisme som i alle fall kunne luket ut 2200 repetisjoner av en enkel strategi. Det kan imidlertid ha vært kontraktsmessige grunner til robotens enfoldighet. Børsen kunne også kanskje ha hindret dette ved å innføre restriksjoner på reversering av ordrer i slike småselskaper, men det ville fjernet daytraderne og omsetningen som de bringer med seg til markedet.

For den vanlige investor er det jo heller ikke åpenbart at det er ulovlig kursmanipulasjon en bedriver når en dytter på kursen. På meget kort sikt er jo tross alt markedet et nullsumspill der den enest tap er den andres gevinst. For daytradere handler derfor hele spillet om å lure andre investorer, så hvorfor skulle det være ulovlig å loppe akkurat denne tungnemme karen? Av den grunn hadde det ikke skadet om børsen hadde lagt inn begrensninger på slik aktivitet på forhånd heller enn å straffeforfølge i ettertid.

Selv for en market maker utstyrt med puls og hjerne er det vanskelig å beskytte seg 100% mot denne type markedsmanipulasjon. Oslo Børs burde derfor kanskje ha strengere regler for børsnotering slik at de minst likvide aksjene som det er vanskeligst å drive market making for, fjernes fra markedsplassen.

Alternativt kan man forsøke å finne måter å drive market making som ikke er så utsatt for markedsmanipulasjon. Én vei å gå er naturligvis å utvikle smartere roboter. I så fall er det ikke nødvendigvis en god idé å straffeforfølge investorer som avdekker feil.


Market maker:
• En aktør som tilbyr likviditet til markedet ved å både være selger og kjøper samtidig. Market makeren stiller en kjøpskurs og en salgskurs og tjener på differansen.
• I enkelte markeder, slik som Oslo Børs, er det kun market maker for de minst omsatte aksjene. Gjennom en avtale med Oslo Børs gis en market maker ansvaret for å tilby likviditet i en bestemte aksje.
• I enkelte markeder, slik som NASDAQ i USA, oppfordres alle investorer til å drive market making ved at man får en rabatt på handelsavgiften dersom en stiller kjøps eller salgskurs.

Read More

Commercial web scanners and the word "suck"

I had an interesting debate on a public mailing list today. It might have started with me casually claiming that commercial scanners are "sucky" - and escalated with both the former CTO of SPI Dynamics and the former director of Watchfire both expressing their displeasure. Their take is fair - but this particular argument is perhaps interesting enough to capture it here in a more coherent form.

Let's begin with a relatively uncontroversial observation: we simply don't know how to build decent web application scanners today - be it in the commercial or the open source world. How bad is the issue? Consider that the following topics essentially remain the Millenium Prize Problems in this field:

• Deciding whether two HTTP responses seen at two different URLs functionally correspond to the same component. Many unrelated pages look very much alike, because of the heavy use of headers, footers, and other templates. Conversely, a single page may change appearance every time it is requested if the content is generated dynamically. Pretty much every single fuzzy matching algorithm used here has spectacular and common failure modes.

  
  

• Deciding what constitutes "page not found" and "error occurred" responses for various parts of the website, a prerequisite for a crawl. This task gets particularly interesting when various URLs are mapped to several different back-end frameworks, a common scenario in enterprise settings; in some of these cases, HTTP response codes are not passed through to the end user, too.

  
  

• Figuring out how the application encodes query parameters and interprets URL paths. Surprisingly, even the most respected and largest enterprise vendors - say, SAP or Oracle - often treat RFCs as a friendly suggestion at best, and invent their own, outlandish conventions for no apparent reason. Throw mod_rewrite into the mix, and things get seriously hairy.

  
  

• Telling whether a particular security attack probe succeeded at all. Consider testing for a buffer overflow: both a successful attack on a vulnerable code, and tripping a security exception due to a well-implemented parameter length check, may result in an identical HTTP 500 response. What next?
  

The list goes on. In the end, automated scanners very often fare poorly when it comes to finding security bugs: they consistently fail to reach or properly recognize all the low-hanging fruit, spew out significant amounts of false positives - and just as often, simply catch fire when attempting to crawl a site in the first place.

This does not mean that web application scanners are worthless; but their primary value lies in equipping a skilled, human pentester with the initial view of the structure of a site; and automating certain cumbersome tasks, such as the execution of brute-force attacks. The reality is harsh: without the right person behind the wheel, the output of such a scanner, no matter how well tabulated and color-coded, tells you next to nothing about how secure your infrastructure is.

Regrettably, skilled pentesters with in-depth vulnerability hunting expertise, and excellent insight into how the web actually works, are exceptionally hard to get; heck, they are even difficult to recognize: there are no meaningful certifications, no particularly useful professional bodies... and even an impressive employment history or a history of conference presentations is a hit-and-miss indicator.

As a result, many commercial entities end up without the low-level security expertise needed to truly benefit from running a web security scanner - and in absence of this, they unrealistically expect the tool to give them some sort of a turn-key insight into the unknown. This never works as expected; and with nobody equipped to reliably evaluate the quality of the crawl, or the accuracy and ingenuity of the probes used, there is not even a proper feedback loop.

The problems the customers have here reflect negatively on the vendors, too: the company eventually accumulates a baggage of institutional customers who do not exert any pressure on improving the products to - let's say - always have cutting-edge SQL injection checks; and heavily focus on more easily verifiable, but peripheral functionality, instead: plug-and-play support for all sorts of internal SSO systems, elaborate reporting capabilities, compliance-related views that can be shown as a proof of due diligence, and so forth. All these features have some value, of course - but ultimately, they divert resources from the one pursuit that matters the most: helping a skilled pentester, and getting better at it.

In this sense, the commercial vulnerability scanner market is, by large, driven by pathological incentives - and will probably remain this way, at least until enough skilled professionals enter the workforce, or - less likely - until a major technological breakthrough is made.

Now, here's an interesting tidbit: have a look at the open-source vulnerability scanner world. Almost all the web application scanning tools that cropped up in the past two years are written by active bug hunters who use these tools in their day to day work, and were unhappy with what commercial tools have to offer. Not all of these alternatives are good, and not all will succeed - but they are developed with a very important goal in mind: to get really good at spotting bugs, and nothing more. Many of them already surpass some of the more stagnant commercial offerings in this department - and the improvement will continue.

I am very reluctant to make sweeping statements about the superiority of one software development model over another - but in this case, it seems to make a real difference, at least today. And, sure, I recognize that this argument goes both ways: the moment those open source developers start deriving most of their income from selling their products, rather than from consulting services, many of the tools will (as one person put it) quickly begin to suck.

Read More

On designing UIs for non-robots

In a typical, attentive human subject, the usual latency between a visual stimulus and a voluntary motor response is between 100 and 300 milliseconds. As should be evident, we do not pause for that long to assess the situation after each and every muscle movement; instead, we routinely schedule series of motor actions well in advance - and process sensory feedback only after the fact, in an asynchronous manner. Within that sub-second window of opportunity, we are simply unable to abort a premeditated action - even if things go wrong.

And here lies an interesting problem: on today's blazing fast personal computers, a lot can happen in as little as one-tenth of that timeframe. Within a browser, windows can be opened, moved around, and then closed; system prompts triggered or destroyed; programs launched and terminated. In such an environment, designing security UIs that take human cognitive limitations into account is a tricky game: any security-relevant prompt that does not enforce a certain amount of uninterrupted, distraction-free, in-focus screen time before accepting user input, is likely completely broken.

Intuitively, this just feels wrong - surely, humans can't be that bad, so the issue can't be that serious - but this is exactly the sort of a fallacy we should be trying to avoid. There is nothing, absolutely nothing, that would make attacks impractical; increasingly faster JavaScript has the ability to programatically open, position, resize, focus, blur, and close windows, and measure mouse pointer velocity and click timings with extreme accuracy; with a bit of basic ingenuity, any opportunity for a voluntary user reaction can be taken out of the equation. That's it: we suck, and there is nothing you can do to change it.

To back this claim, let's have a look at the recently-introduced HTML5 geolocation API; the initial call to navigator.geolocation.getCurrentPosition() spawns a security prompt in Firefox, Opera, Chrome, Safari, and a couple of other browsers. This UI does not implement a meaningful delay before accepting user input - and so, this
crude and harmless Firefox proof-of-concept can be used to predict the timing of mouse clicks, and steal your location data with an annoyingly high success rate. This particular vector is tracked as Mozilla bug 583175, but similar problems are endemic to most of the new security UIs in place; the reason is not always simple oversight, but often, just explicit opposition to the idea of introducing usability roadblocks: after all, to a perfect human being, they are just a nuisance.

Fine-grained click timing is, of course, not where the story ends; it has been demonstrated time and time again that with minimal and seemingly innocuous conditioning, healthy and focused test subjects can be reliably duped into completely ignoring very prominent and unusual visual signals; the significance of this problem is unappreciated mostly because not many exploit writers are behavioral scientists - but that's not very reassuring thought.

There is some admirable work going on to make browser security messaging more accessible to non-technical users; but I'd wager that our problems run deeper than that. We are notoriously prone to overestimating the clarity of our perception, the rationality of our thought, and the accuracy of our actions; this is often a desirable trait when going through your life - but it tends to bite us hard when trying to design security-critical software to be used by other human beings.

We need to fight the habit the best we can, and start working on unified, secure human-to-machine interfacing in the browser. If we dismiss our inherent traits as an out-of-scope problem in security engineering, we will lose.

PS. On a somewhat related note, you may also enjoy Jesse Ruderman's recent 10-minute presentation about UI truncation attacks.

Read More

BP, oljekatastrofer og risikospredning

Oljefondet har fått mye ufortjent kritikk for sin eksponering mot det brittiske oljeselskapet BP i etterkant av oljekatastrofen i Mexicogulfen. Siden oljerelatert virksomhet utgjør en betydelig del av verdens verdiskapning så tilsier referanseindeksene som oljefondet følger at de gjør store investeringer i slike bedrifter. En kan alltids kritisere fondet for ikke å ha ringt 800-nummer for å få hjelp til å forutse krisen, men utover det blir kritikken av investeringene i BP nokså meningsløs.

Et mer grunnleggende spørsmål er imidlertid hvorfor referanseindeksene inneholder oljeaksjer i det hele tatt. Norge er allerede overeksponert mot oljeprisrisiko gjennom mange kanaler i form av skatteinntekter, eierskap i Statoil, og ikke minst eierskapet til ressurser som fortsatt ligger på havbunnen (SDØE). Om vi priser inntektene fra disse virksomheter som aksjer og regner det som en del av oljefondet, så har vi trolig en eksponering mot oljemarkedet alene på i alle fall samme størrelsesorden som det eksisterende fondet på snart tre tusen milliarder kroner.

En av de viktigste innsiktene som finansteori kan gi er at om en sprer investeringene så senker en risikoen uten at det gir lavere avkastning. Dette konseptet er altså så nært en gratis lunsj som en kommer i økonomifaget. Staten kan oppnå slik risikospredning for eksempel ved å selge seg ned i Statoil og SDØE, men det er ikke politisk mulig. En enkel, kostnadsfri og upolitisk løsning vil imidlertid være å renske ut alle oljerelaterte aksjer fra oljefondet. Så hva er årsaken til at en ikke allerede har gjort det?

Finansdepartementet har naturligvis tenkt nøye gjennom akkurat det, og argumentene for å la fondet fritt investere i oljeaksjer er flere. Blant annet mener departementet at oljefondets beholdning av oljeaksjer er liten og at lav samvariasjonen med oljeprisen uansett tilsier at gevinsten ved denne type risikospredning er minimal. I tillegg har departementet det noe selvmotsigende argumentet at olje og gass sektoren utgjør en så stor andel av den globale indeksen og har gitt så stor avkastning at det vil være galt å utelukke slike aksjer.

Det er imidlertid flere svakheter med denne argumentasjonen. For det første er det jo slik at ettersom oljefondet vokser og reservene svinner så vil oljeaksjene i fondet utgjøre en stadig større andel av vår samlede formue. Allerede i dag er olje- og gassaksjene trolig verdt om lag 20% av SDØE. Fordelen ved å luke ut oljeaksjene fra fondet vil altså bare øke med tiden. Det kan derfor være greit å gjøre noe med saken nå.

I tillegg ser det ut til at departementets anslag på risiko er feil, ettersom de i praksis har lagt til grunn at verdien av landets samlede oljeformue kan oppsummeres i spotprisen på olje. Oljeformuen avgjøres imidlertid av forventet fremtidig oljepris, akkurat slik verdien på internasjonale oljekonsern fastsettes i aksjemarkedet. Risikoen knyttet til statens oljeverdier gjenspeiles derfor trolig bedre ved å anta at de er nær 100% korrelert med kursutviklingen for internasjonale oljeselskap, og ikke havparten av dette slik som spotprisen indikerer. Dette vil i så fall gi helt andre anslag på fordelene ved risikospredning.

Som departementet nevner så har imidlertid avkastningen på oljeaksjer vært høy historisk. Det vil likevel bære helt galt av sted om en skal legge til grunn ulike sektorers historiske avkastning ved valg av portefølje, uten å ta hensyn til at slik avkastning er en indikasjon på særlig høy risiko.

Departementet mener uansett det er vanskelig å droppe oljeaksjene fordi de utgjør en så stor andel av verdens aksjemarkeder, men det er nettopp derfor disse aksjene bør utelukkes. Isolert sett vil det medføre en mer konsentrert portefølje. Det er likevel sammensetningen av vår totale portefølje, inkludert fremtidige skatteinntekter, produksjonsrettigheter og Statoil, som er avgjørende. Ideelt sett bør vår eksponering mot olje være omtrent som verdensmarkedets, dvs. om lag 12,5%. Den faktiske andelen er trolig langt over 50%.

Read More

Cookies v. The People

For some reason, The Wall Street Journal launched a new, large-scale offensive on web cookies - and decided to focus on the purported malice of Microsoft in particular:

"All the latest Web browsers, including Internet Explorer, let consumers turn on a feature that prevents third-party browser cookies from being installed on their computers. But those settings aren't always easy to find. Only one major browser, Apple's Safari, is preset to block all third-party cookies, in the interest of user privacy.

The Internet Explorer planners proposed a feature that would block any third-party content that turned up on more than 10 visited websites, figuring that anything so pervasive was likely to be a tracking tool.

When he heard of the ideas, Mr. McAndrews, the executive involved with Microsoft's Internet advertising business, was angry, according to several people familiar with the matter. Mr. McAndrews feared the Explorer group's privacy plans would dramatically reduce the effectiveness of online advertising by curbing the data that could be collected about consumers."

I do not have any insight into the decision process behind browser features at Microsoft - and it would be unfortunate if this factor alone had such a significant bearing on the final outcome. I do know, however, that the characterization of third-party cookie blocking as an important privacy feature is grossly misguided at best - and that there are compelling technical arguments to be made in favor of not enabling it by default.

The fundamental problem is that for better or worse, browsers necessarily make it trivial to track users across cooperating websites, without any need for the actors to appear malicious or evil. Quite simply, every computer system is unique, and browsers, by design, offer a substantial insight into it: very few other people share exactly the same browser and OS version, uptime, browser window size, installed fonts and applications as you - and so, reliable browser instance fingerprinting is certainly not science fiction.

This obvious possibility aside, there are many types of core web features that offer functionality essentially identical to cookies, and are depended on by much of the Internet; for example, RFC2616 caching allows long-lived tokens to be stored and retrieved through HTTP headers such as ETag, or simply embedded in persistently cached JavaScript code. The only reason why cookies are preferred is that they are well-known, purpose-built, have well-understood security properties, and can be managed by users easily. I encourage you to check out Ed Felten's excellent essay for more: the alternatives are very easy to embrace, but will suck for consumers more.

It is possible to build a reasonably anonymous browser, but only by crippling many of the essential features that make the modern web tick; products addressed to the general public should probably not go there. Disabling third-party cookies alone feels like a knee-jerk reaction that really does nothing to improve your privacy - and actually impacts your security. A striking example is that a ban on third-party cookies makes it very difficult to create XSRF-resilient single sign-on systems for complex, SOP-compartmentalized web applications (at least unless you introduce a dependency on JavaScript - the other Great Satan of the Internet).

To add insult to injury, because of compatibility issues, the existing third-party cookie blocking mechanisms gradually morphed into honor systems anyway: one implementation allows cookies to be set once the third-party frame is interacted with (which can be facilitated without user knowledge by having a transparent, invisble frame follow the mouse pointer for a while). Another allows cookies to be read and modified after the initial visit to a particular "third-party" site. A yet another implementation allows servers to declare good intentions by specifying a special HTTP header (P3P) to simply bypass the mechanism.

Given the way the web works, the most realistic way to improve user privacy is to create a community standard for notifying well-behaved players about your privacy preferences, and allowing them to comply. It will actually work better than the inevitable technological whack-a-mole with cookie-equivalent mechanisms: malicious parties will have the ability to track you for the foreseeable future anyway - but with explicit preference declarations, parties who want to be seen as reputable would not be able to assume that cookies are blocked simply because this is how your browser ships - and promptly switch to an alternative tracking mechanism in good faith. Commercial search engines obey robots.txt, so this system has a chance of working, too. If you disagree and distrust corporations, legislative approaches to privacy protection may be your only remaining bet.

Speaking of advisory privacy mechanisms, Microsoft actually deserves some credit rather than blame - namely, for supporting the aforementioned P3P signaling in their products: the associated HTTP headers are used to make cookie policy decisions in Internet Explorer, and not in any other browser. Alas, the protocol is a bit of a cautionary tale by itself: W3C attempted to create a complex, all-encompassing, legally binding framework to compel businesses to make honest, site-wide declarations; and the concept eventually collapsed under its own weight. Large businesses are extremely hesitant to use P3P, out of the risk of increasing their legal footprint; while small-scale web developers are simply intimidated by the monumental 110 page specification, and copy off recipes from random places on the web, with little or no regard for their intended meaning.

So yeah, privacy is hard. Blaming a browser vendor is easy. It's just not very productive.

Read More