Browsing articles tagged with " BATS"

Unnecessary Catastrophic Risk Events

Aug 24, 2012   //   by admin   //   Blog  //  No Comments

Lead Analyst: Cal Braunstein

Knight Capital Group, a financial services firm engaged in market making and trading, lost $440 million when its systems accidentally bought too much stock that it had to unload at a loss and almost caused the collapse of the firm. The trading software had gone live without adequate testing. In other news, Wired reporter Mat Honan found his entire identity wiped out by hackers who took advantage of security flaws at Inc. and Apple Inc.

Focal Points:

  • Knight Capital – which handled 11 percent of all U. S. stock trading so far this year – lost $440 million when its newly upgraded systems accidentally bought too much stock that it had to unload at a loss. The system went live without adequate testing. Unfortunately, Knight Capital is not alone in the financial services sector with such a problem. NASDAQ was ill-prepared for the Facebook Inc. IPO, causing losses far in excess of $100 millions. UBS alone lost more than $350 million when its systems resent buy orders. In March, BATS, an electronic exchange, pulled its IPO because of problems with its own trading systems.
  • According to a blog post by Mat Honan “in the space of one hour, my entire digital life was destroyed. First my Google account was taken over, then deleted. Next my Twitter account was compromised, and used as a platform to broadcast racist and homophobic messages. And worst of all, my AppleID account was broken into, and my hackers used it to remotely erase all of the data on my iPhone, iPad, and MacBook.” His accounts were daisy-chained together and once they got into his Amazon account, it was easy for them to get into his AppleID account and gain control of his Gmail and Twitter accounts. It turns out that the four digits that Amazon considers unimportant enough to display on the Web are precisely the same four digits that Apple considers secure enough to perform identity verification. The hackers used iCloud’s “Find My” tool to remotely wipe his iPhone, iPad and then his MacBook within a span of six minutes. Then they deleted his Google account. Mat lost pictures and data he cannot replace but fortunately the hackers did not attempt to go into his financial accounts and rob him of funds.
  • All one initially needs to execute this hack is the individual’s email address, billing address and the last four digits of a credit card number to get into an iCloud account. Apple will then supply the individual who calls about losing his password a temporary password to get access into the account. In this case the hacker got the billing address by doing a “whois” search on his personal domain. One can also look up the information on Spokeo, WhitePages, and PeopleSmart. To get the credit card information the hacker first needed to get into the target’s Amazon account. For this he only needed the name on the account, email address, and the billing address. Once in, he added a bogus credit card number that conforms to the industry’s self-check algorithm. On a second call to Amazon the hacker claimed to have lost access to the account and used the bogus information in combination with the name and billing address to add a new email address to the account. This allows the hacker to see all the credit cards on file in the account – but just the last four digits, which is all that is needed to hack into to one’s AppleID account. From there on, the hacker could do whatever he wanted. Wired determined that it was extremely easy to obtain the basic information and hack into accounts. It duplicated the exploit twice in a matter of minutes.

RFG POV: The brokerage firm software failures were preventable but executives chose to assume the high risk exposure in pursuit of rapid revenue and profit gains. Use of code that has not been fully tested is not uncommon in the trading community, whereas it is quite rare in the retail banking environment. Thus, the problem is not software or the inability to validate the quality of the code. It is the management culture, governance and processes that are in place that allows software that is not fully tested to be placed into production. IT executives should recognize the impacts of moving non-vetted code to production and should pursue delivering a high quality of service. Even though the probability of failure may be small, if the risk is high (where you are betting the company or your job), it is time to take steps to reduce the exposure to acceptable levels. In the second case it is worth noting that with more than 94 percent of data in digital form commercial, government, and personal data are greatly exposed to hacking attacks by corporate, criminal, individual, or state players. These players are getting more sophisticated over time while businesses trail in their abilities to shore up exposures. Boards of Directors and executives will have to live with the constant risk of exposure but they can take steps to minimize risks to acceptable levels. Moreover, it is far easier to address the risk and security challenges in-house than it is in the cloud, where the cloud provider has control over the governance, procedures and technologies used to manage risks. IT executives are correct to be concerned about security in cloud computing solutions and it is highly likely that the full risk exposure cannot be known prior to adopting a vendor’s solution. Nonetheless, Boards and executives need to vet these systems as best they can, as the risk fiduciary responsibility remains with the user organization and not the vendor.