• Are all proxies actually security assets?

    ​Bear with me readers, in this article I posit a controversial viewpoint. That viewpoint is that all existing technologies acting as proxies to transit security zones must be considered a security asset and that the security team needs to get more involved in load balancer design and operations

  • ​Mossack Fonseca - Insider Threat - What would you do?

    So with all the press related to the Panama Papers I began thinking again about insider threat. So here is a quick list of suggested actions specifically to tackle data leakage/whistleblowing/insider threat. This is a particularly difficult challenge in information security as you often need to provide access to all customer records to the lowest level of employees within the organisation to facilitate timely customer service processes.

  • From IT security to information security and beyond...

    Over the years, yours truly has been heavily involved with the evolution of the modern “comuter security” function in a number of organisations. I thought it might benefit readers to receive a brief history lesson, take a current pulse check and look forward to the future of the evolution of the information security function.

  • What will 2015 bring to infosec?

    It’s always wonderful to start a new year. A new year brings a fresh perspective and renewed enthusiasm. So what do I think twenty-fifteen will bring us?

  • Citizens not Suspects - Notes on Mandatory Data Retention

    Why should a CSO care about the government's mandatory data retention scheme? It’s your customers’ metadata. It’s your company’s metadata.

  • Icloud, youcloud, wecloud- thoughts on consumer cloud service security

    The recent compromise of icloud backups of celebrities has piqued interest in the security of consumer cloud services. To paraphrase Del Harvey from twitter, when you have a million events a day, a one in a million event happens once a day.

  • Once upon a information security

    Let me tell you a story, the story of information security.

  • Cloud DevOps and Security

    There is a buzz in Australia, post Amazon’s Web Services Summit, around a few cloud related concepts. I will try and distill.

  • Some proposed laws of big data

    At the recent CSO Perspectives Roadshow I was on a panel with the esteemed David Lacey, he suggested just like Asimov's laws for robotics we need some clear maxims for the security and privacy management of big data.

  • Open Letter to Canberra: a cyber security policy briefing paper

    I just heard that Australia's top cyber security tsar hadn't heard of Tor, the privacy protecting software used by human rights activists and the privacy aware. Well Sachi Wimmer, this blog post is for you!

Matthew Hackling

Matthew has over ten years experience operating solely in the area of information security, holds a Bachelors degree in security management from ECU and is also a CISSP. He is a former Account Director in Deloitte’s Security & Privacy Services practice. Matthew has led security testing teams on assessments of large core systems replacement projects for banking institutions. He operates more in the area of information security governance these days, despite his urges still stay a bit technical. Hence he plays with backtrack linux, metasploit and new web application security assessment tools in his rare free time. Currently he runs his own consultancy called Ronin Security Consulting and holds the title of General Manager of Security Testing at Enex TestLab. He is an active member of the Australian Information Security Association, and held the office of Melbourne Branch Executive for a number of years. Matt’s security blog is called Infamous Agenda and he is an active twitter user with the handle @mhackling
  • How to save $2BN by laying off one employee

    So a trader at UBS lost 2.3 billion dollars. To put that in perspective that is $2.3B of cold hard liquid cash that is gone gone gone. UBS announced plans in August to lay off 3500 employees to reduce future expenditure over the next three years by a similar amount (around $2.2B USD). A cynic would ask if there were any risk and compliance personnel headcount in that slash? The current gallows humor joke is that the CEO could have saved $2B by laying off one employee rather than 3500. There have been at least nine rogue trading scandals in recent memory. Of note are the following: • FIRST - Nick Leeson (827M Pounds) at Barings Bank - caused collapse of the bank • BREAKING 1 BILLION - Toshihide Iguchi ($1.1B) at Resona Holdings • BREAKING 2 BILLION - Yasuo Hamanaka ($2.3B) at Sumitomo • BIGGEST - Jérôme Kerviel €4.9B) at Société Générale • LATEST - Kweku Adoboli $2.3B at UBS Now before you start trying to drum up some support for your information security endeavors by quoting $2.3B as a potential saving, let's have a look at how information security can and can't help with the issue of fraud. Firstly the traders were all trusted authorised employees doing what they were employed to do and using systems they were authorised to access, performing activities that were expected. They just escaped their shackles and took larger risks than they were authorised to by finding holes in internal control practices. From my meager research undertaken it appears that timing of activities to evade monitoring practices was common in many of these instances, very similar to "check kiting" or "ponzi schemes". Good questions to ask if you had the chance of these institutions would be: • Did any internal control reports detect any irregularities previous to the major incident? • Was this their first transgression? • Were they formally counseled in the past? • Was this gambling outside of their daily limit with or without the tacit approval of management? • What was the risk management culture like within the organisation? Let's talk about some traditional information security controls that we could potentially apply to this problem and how they can and can't help us: Application Security Controls Application authentication wouldn't have helped, as the traders were authorised users of the trading applications. Role based access control/implementation of segregation of duties/dual auuthorisation potentially could have helped if front office and back office functions were in the same application. Front office (those rabid trader/gamblers) and back office (confirmation/settlement/accounting/risk management/compliance) functions are required to be independent. Often these systems are not a single integrated application but a number of applications that are interconnected. Infrastructure Security Controls Anti-Malware, HIPS and NIPS damn well wouldn't have worked! There's no signature definition for "employee has gone NUTS today!" A Security Event and Information Management solution definitely wouldn't have helped as the transactions were valid "authorised" application level transactions not platform or network logs or IDS alerts. If you think you can help with this issue as an information security professional, maybe you should adjust your expectations. Ask yourself these questions; • Do I understand complex financial instruments? • Do I understand business processes for trading and how timing and changes in the order of a series of complex activities can subvert internal controls? • Am I a financial application architect or developer or do I have the influence to persuade a vendor to make changes to an application? How can you help? As an information security professional in a financial institution potentially consider some of the following activities, which may actually help: • Develop friendly relationships with your fraud team and internal audit team • Help your organisation inventory and risk assess applications and supporting systems. What are the most critical applications and supporting systems? • Help introduce the concepts of threat modeling and attack trees to your fraud and audit teams. It may help them in designing controls if they start to think like their prey! • Lobby for the implementation of effective internal controls within trading/treasury applications, this includes: ◦ requirements for controls ◦ documentation of how the controls are to be implemented and monitored. These could include restrictions on daily limits for traders, dual authorisation for high vale trades in the front office and back office real time monitoring and even pattern matching for individuals activities. ◦ testing of controls to make sure they are effectively configured and monitored • Lobby for fraud monitoring applications and resources for the fraud team • Lobby for cultural change and employee assistance programs • Conduct security awareness training, especially focus on the dangers and implications on the individual of sharing passwords/smart cards and the concepts of role based access control/segregation of duties. • Schedule application security and infrastructure security testing of critical applications. It may help if once the internal controls are implemented that they can't be bypassed with a web proxy and some parameter manipulation. As always I welcome your feedback and encourage you to share your experiences!

  • CSO Bloggers

    Coming soon....