how to protect trading strategies for a colocated server

Discussion in 'Automated Trading' started by trend2009, Dec 9, 2009.

  1. They USE Type-1 encryption hardware and Tempest approved hardware.
     
    #31     Dec 10, 2009
  2. CGNobody

    CGNobody

    Can you explain how encryption hardware would even be a factor here. Hardware allows encryption of network data going in/out to prevent spying on data flows from the outside.

    I don't see how any hardware can help with the question at hand. You could use self-encrypting drives but this is clearly unnecessary since all you need protected is your application, not the whole content of your drive. Might be some hedge fund manager got ripped off by a hardware vendor and bought these specialized drives without knowing alternatives.
     
    #32     Dec 10, 2009
  3. Jerry030

    Jerry030

    I can't give you any real help there...it's not my area of skill or expereince, but good luck with it.

    I would suggest to be on the safe side you stuff the application with a lot of dead and useless code. If it is cracked that makes it much harder to understand the design and logic, assuming you want to protect the design as well as the operation.
     
    #33     Dec 10, 2009
  4. the latency involved in these security measures would kill the trade. In the real world of auto-systems you have to give your guys full access and incentivize everyone involved to want nothing but the most profitable system. What is best for the group is best for the individual.

    By the time you create false signals out of one box and then have another process them, etc. and have it all encrypted, etc. you won’t be competitive with other guys who straight up run the same trade. Anyone who has the ability to change the code/logic in the system needs to be granted full access to the source code and IMO there is no way around that. You would spend more time trying to protect the work they wrote – from them and trust would be non-existent, etc. The reality is most ATS systems work well only in the market conditions they were written and most also have a short lifespan. The goal is to get them up & trading ASAP and then work on building out the next trade – not trying to secure/protect anything existing.
     
    #34     Dec 10, 2009
  5. Jerry030

    Jerry030


    That's an interesting point of view.

    True I suppose of the predictive future window of your trading system is only 20 to 30 seconds. It that case a trade timing differece of 50 ms could be an issue. However if you can predict future market characteristics an hour or 10 hours into the future a delay of a few more ms is totally irrelevant for trade execution and it would protect your system. Stasticaly it would depend on the average trade lenght and the varaince in price during that period realtive to the varaince of fills for a 10, 50 100ms, etc. fill window...correct?

    In any case below is a story on what happened to Goldman when they fully trusted one of ther programmers... let the system designer beware!

    The Real Story of Trading Software Espionage

    While the 32MB of Goldman Sachs' proprietary algorithmic trading code allegedly stolen by Sergey Aleynikov makes for great news, it also highlights the new significance of high-frequency trading — which is built on this technology — in the marketplace. By Rob Iati, Partner, The TABB Group JULY 10, 2009


    Much has been made of the 32MB of Goldman Sachs' proprietary algorithmic trading code ("trading secrets") allegedly stolen by Sergey Aleynikov, now portrayed in the financial media as the new Julius Rosenberg, Aldrich Ames, Robert Hanssen
    and John Walker all rolled into one. That may prove to be true; but while it makes for a great news story at this point in time, it highlights the new significance of high-frequency trading — which is built on this technology — in the marketplace. <snip>...........

    full story at http://tech.groups.yahoo.com/group/Neural_Networks_and_Knowledge_Discovery/message/693
    or
    http://advancedtrading.com/algorithms/showArticle.jhtml?articleID=218401501
     
    #35     Dec 10, 2009
  6. Unless the computer is physically tamperproof, you have no assurance your code can't be stolen. For example, it's easy to clone a disk drive by booting off a USB drive with suitable software - forensics people do this - and one can even plant software on the disk to monitor what the trading software does.
     
    #36     Dec 10, 2009
  7. heech

    heech

    1) Encrypted partitions are a good start. Crude raw copy of the drive is useless.

    2) Beyond that... lock down your system with some of the mil-quality security Windows can provide. I run Windows Server, and use two-factor logins for this purpose: physical USB key + PIN code required for login to the system, and only one account enabled.
     
    #37     Dec 10, 2009
  8. that story is total BS and GS/media hype. The guy brought work home and used a proxy server to email stuff to himself. If you know anything about the code/algos in question you'd know that it's not worth thr programmer's time to try and steal this - they can just re-write it. yeah it's labor intensive but easier than risking jail time, etc.

    GS just needed an excuse to lock this guy's IP down so that's what they did.
     
    #38     Dec 10, 2009
  9. Jerry030

    Jerry030

    You seem to be a real expert here. When ther is a news story that shows there may be a few holes in the"gotta trust your programmer" theory, you know all about details not reported in the media.

    Are you a reporter? ...with GS security department? ....perhaps in local law enforcement? ..... a globally known security consultant?
    I'm really curious what you do when not posting on ET. Tell us, please.
     
    #39     Dec 10, 2009
  10.  
    #40     Dec 10, 2009