Review of Real Life Security Incidents

Question: Discuss about the Review of Real Life Security Incidents. Answer: Introduction As mentioned in the previous section, a breach is an accidental exposure of data. There is no malicious intent. The working parties in a breach are insiders to an organisation. This report is limited to a publicly available information on breaches during September-December 2015. Suppose a person visits a sexual health clinic and opts for undergoing a clinical test. In the small community that the clinic serves, many people know each other by name. Now, suppose that the entire list of individuals that chose to take the test mentioned above is broadcast to each other. What would be the consequences? Would the people, most of whom may be acquaintances of each other, now see each other differently? This section explores one such incident. 56 Dean Street clinic, which specialises in family planning and sexual health, also administers HIV (Human Immunodeficiency Virus) tests. HIV test is a way to ascertain if an individual has the till-now incurable and debilitating disease of AIDS (Acquired Immune Deficiency Syndrome). AIDS itself has huge social implications that may make a person suffering from this disease at a significant disadvantage in her day-to-day life, with stigma and discrimination ("Stigma and Discrimination", n.d.), and possibly social isolation (Brown, 2016). The aim of the discussed hacking attack was money. Also, this attack was planted over two years and exploited for months. The attack was coordinated internationally, and novel methods for swindling the money were devised. The new techniques were used to avoid detection and also, the majority of the illegal transactions were of a relatively insignificant amount. All these details have made public by a private security company, which under the restrictions of Non-Disclosure Agreement (NDA), is prevented from naming the banks. Any bank affected itself has not come forward and publicly disclosed the attack. How could the secure banking systems be compromised? How could the planting of the malware go on for about two years without no one or no system detecting it Problem The problem was the fraudulent activities are done in the banking system, which led to the transfer of real money to unauthorised people (the criminals themselves). Additionally, the stealth used by the criminals fooled the individuals and the systems of the banks into letting these transactions pass off as routine. Also, the members of this particular attack impersonated as officers and staff of the banks to "oversee" operations. The failure to detect fake staff was also missed. Review of Two Real-life Security Incidents The most valuable asset of an organisation is intangible - data (Poole, 2007). Anything that is worth stealing will be stolen, and in today's information-based society, data provides a lucrative opportunity for easy ways to make money. In addition to big-name targets (Granville, 2015), smaller companies are also being targeted by attackers (Connolly, Gardiner, 2015). Also, not only are the skills and resources of the attackers increasing with time, the threat landscape itself is evolving (Security, n.d.). Thus the security of computers, networks, and data is a moving target. This report focuses on reviewing two real-life information security incidents. The first part discusses a breach, while the second talks about a successful hacking attack. To begin, let us differentiate between a breach and a hack (Landt, 2016). A breach is an accidental and non-malicious exposure of confidential information from inside the organisation. A hack is a willful and malicious attack from outside to c ompromise the organisation. Computer Security Breach Incident Problem At the 56 Dean Street clinic, as is the case with almost every organisation, newsletters are sent to people who have used their services. Whether or not the people have expressly consented to receive the newsletter when they provided their email address is not relevant to the current discussion. Individuals who opted for HIV test had their data bundled together in a group. This group was sent a regular email newsletter. What happened is that the employee in charge of sending out the email newsletter sent, in addition to the bulletin, details of name and email addresses of every person who had undergone HIV test in that clinic. How and Why the Breach Occurred The breach took place while the employee was compiling the list of HIV tested customers as a name and email pair. This was copied and then supposed to be pasted in blind carbon copy (BCC) field of the email compose screen. The employee pasted it into carbon copy (CC) field of the compose screen (Ford, 2015). Recipients in BCC field are unaware of other recipients, while in CC are aware of all those who have received a particular email message (Hoffman, 2012). This mistake resulted in all the people taking HIV test receiving the names and email addresses of all other such people (Burgess, 2016). The breach occurred because of laxity towards personal and confidential data. Such data is privileged information and not for the consumption of public. The lack of diligence is at multiple levels. At the management level, a stricter, possibly automated procedure, should have been used. At the individual employee level, he should have been alert and exercised care before hitting the send button. Possible Solutions As discussed in the previous section, the reasons for such a breach were not giving private data the respect it deserves, no formal rules, manually touching such data and carelessness of the employee handling the distribution of email newsletters. Keeping these reasons in mind, we propose the following solutions to prevent such a situation. It must be noted that once an email leaves the sending server, there is no way to cancel it. Email is instantaneous and even though the sender and receiver may be sitting on opposite sides of the Earth, still once and email hits even a single external server, it is beyond the point of no return (Hoffman, 2013). Confidential data is confidential for a reason and must be treated with respect, and this should show throughout the hierarchy of the organisation. To this end, comprehensive formal rules are suggested to make everyone clear as to what is at stake - not only the data but also the financial and legal implications, should it be breached. Next, every person touching this data must be logged, so that the actual person responsible for any action on the data can be traced, and handled accordingly. A better process can be to maintain automated lists (which only senior staff and database administrators can access) and then provide software with the newsletter content and the software will BCC the newsletter to every person in the list. No manual contamination of the process will be possible in such an arrangement. If there has to be a manual sending, then the employee in charge of each issue must be logged, and that person must be made aware that in the case of any data breaches occurring du e to her, she will be personally responsible for it. Computer Hacking Incident Hacking is an active process. Someone somewhere is motivated enough to use her skills and resources to attempt to attack, invade, and compromise a computer system. Malicious intent is the hallmark of a hacking attempt. The motivations may be amusement, financial, revenge, or patriotic. This report will select one publicly well-known hacking case between 2012 to 2016, and explore it. Financial and banking systems are tested thoroughly. Various laws and regulations exist which help in maintaining the security of these information systems. These institutions inspire trust in the customers as well as the employees. Still, banks are where the money is, and thus they are one of the evergreen targets. The case study chosen is about attackers infiltrating the banking systems using malware, observing the procedures and routine activities via the data sent by the malware on the computers of the banking systems (Sanger, Perlroth, 2015). Who Were Affected and How In this attacking operation, primarily the banking system was affected. Now, cash was extracted from ATM (Automated Teller Machine) machines remotely by hackers. This money belongs to the bank until some authorised person inserts his card and withdraws some amount. Money was illegally transferred from certain accounts to some fake accounts which were created for this purpose only. Most of the customers can be assumed to be alert of their balances. Now, what these hackers did was inflate (artificially of course) the balance in some account and then transfer the excess to their fake account. The original owner of the bank account which served as the launch pad still had the same balance in his account, thus not triggering any out-of-ordinary suspicion unless the detailed statement was analysed. In any case, the money was transferred. Whose money was it? It was the bank's money. Thus, it is concluded that the banks per se were affected and lost real money. The individual account holders were not affected in that their total balance remained the same. However, this incident showcases that the entire system has been compromised, and any determined and resourced attackers can bend the banking and financial system to their will. How Was the Attack Carried Out This attack too had a simple method - email links. The hackers sent emails to employees which convincingly looked as if they came from colleagues. The clicking of an innocent looking link enabled the hackers to download malware on the computers of the banks. The software then trawled the network to identify the central computers. When the administrator computers were located, a further software was downloaded from the hacker servers, which allowed key-logging, screenshots, screencasts, and then uploaded all these to the hackers. To be fair, the hackers expended a tremendous amount of effort to understand the workings of the banks. Critical to the success of the attackers' mission was mimicking the bona fide operations and staff completely. Once, the internal workings were understood, then the next phase of the attack was simpler. Show up at the right place in the right attire and leave with the cash. Remotely order some fraudulent transactions that real money to some temporary accoun ts. Other novel methods of transferring money were also devised. How Could the Attack Have Been Prevented As explained in the previous section, many chinks in the baking armour have been exposed. The faults begin with the emails that were able to bypass any automated checks and reach the employees' inboxes. Some software should have automatically scanned the emails and the links for malicious code or links. Next, the employee must always be on guard to the slightest suspicion. If necessary, the sender of the email may be personally contacted at his official email address confirming the suspected email message. The firewalls should be sensitive not only to the incoming traffic but also the outgoing traffic. Such an arrangement may have been able to intercept when the key logs, screenshots and videos were being sent back to the hackers. Finally, measures should already have been secure enough, but now need to be updated to prevent any impersonations. Additionally, expending more resources to more frequent cross-checking of accounts is recommended. Conclusion The idea from both the case studies seems to be that the human link of a security chain is often the weakest. Incidentally, both the case studies used emails as their attack medium, and critical to their success was fooling the humans into clicking target links. In addition to security alerts, perhaps logging of the links opened by the employees will serve as a motivation for the employees to exercise good diligence. Also, case-specific measures have been recommended. References Brown, A. (2016). Social Effects of HIV AIDS. LIVESTRONG.COM. Retrieved 30 March 2017, from https://www.livestrong.com/article/19464-social-effect-hiv-aids/ Burgess, M. (2016). London HIV clinic fined 180,000 for 'serious' data breach. WIRED UK. Retrieved 30 March 2017, from https://www.wired.co.uk/article/56-dean-street-fine-data-protection-hiv Connolly, B., Gardiner, B. (2015). Case study: When a hacker destroys your business. CIO. Retrieved 30 March 2017, from https://www.cio.com.au/article/569410/case-study-when-hacker-destroys-your-business/ Ford, N. (2015). Londons 56 Dean Street clinic leaks HIV status of 780 patients. IT Governance Blog. Retrieved 30 March 2017, from https://www.itgovernance.co.uk/blog/londons-56-dean-street-clinic-leaks-hiv-status-of-780-patients/ Granville, K. (2015). 9 Recent Cyberattacks Against Big Businesses. Nytimes.com. Retrieved 30 March 2017, from https://www.nytimes.com/interactive/2015/02/05/technology/recent-cyberattacks.html?_r=0 Hoffman, C. (2012). Whats the Difference Between CC and BCC When Sending an Email?. Howtogeek.com. Retrieved 30 March 2017, from https://www.howtogeek.com/128028/htg-explains-whats-the-difference-between-cc-and-bcc-when-sending-an-email/ Hoffman, C. (2013). Why You Cant Undo Sending an Email (and When You Can). Howtogeek.com. Retrieved 30 March 2017, from https://www.howtogeek.com/161762/why-you-cant-undo-sending-an-email-and-when-you-can/ Landt, K. (2016). Breach vs. HackThe Differences You Need to Know to Protect Your Company. Blog.eiqnetworks.com. Retrieved 30 March 2017, from https://blog.eiqnetworks.com/blog/breach-vs.-hack-the-differences-you-need-to-know-to-protect-your-company Poole, O. (2007). Network Security (1st ed., p. 140). Routledge. Sanger, D., Perlroth, N. (2015). Bank Hackers Steal Millions via Malware. Nytimes.com. Retrieved 31 March 2017, from https://www.nytimes.com/2015/02/15/world/bank-hackers-steal-millions-via-malware.html?_r=0 Security, E. ENISAs Cyber-Threat overview 2015 ENISA. Enisa.europa.eu. Retrieved 30 March 2017, from https://www.enisa.europa.eu/news/enisa-news/enisa2019s-cyber-threat-overview-2015 Stigma and Discrimination. Web.stanford.edu. Retrieved 30 March 2017, from https://web.stanford.edu/group/virus/retro/2005gongishmail/hivsocial.html