Tuesday, December 5, 2017

MedSec v. SJM: Insecure Pacemakers

            People throughout the globe have health issues with various parts of their bodies and in differing degrees. These may be acute or chronic, or life threatening. An issue that is present involves cardiac problems. For persons with cardiac issues, a defibrillator/pacemaker is vital and works best with the patient. There are a number of manufacturers of this product, with each having several models. As the patients require these to live, in case there were to be an issue, if an attacker were to compromise a unit, the patients could be placed in mortal peril. The unit being compromised may also allow for unauthorized access of protected health information (PHI) (White, 2015). This could provide for a HIPAA violation (Kohgadai, 2016). This issue could be a very costly learning opportunity for the manufacturer. Medical records are prime targets for the attackers. When there happens to be a compromise of this type, merely the fines are massive. This does not however factor in the costs for forensic work to review the incident.
            With these devices, there has been any issue with this being a known issue, yet net addressed by the manufacturer. The data indicates the manufacturer are unprepared in the area. A survey completed in 2017 from the Ponemon Institute on behalf of Synopsys indicated only 17% of the manufacturers have worked towards appropriate cyber security controls (Dellinger, 2017). This lack of focus is due to many issues, including but not limited to the lack of adequately trained staff, senior management not appreciating the short- and long-term financial and operational risks, issues with testing and other significant issues.
History
            Medical connected devices have been present and in use for decades. Consumers have presented the need for assistance with bodily functions. Although these were designed with the best intentions and functionality in mind, there were still issues with the equipment. From 1990-2000, the FDA issued recalls on 114,645 devices (Burns, Johnson, & Honeyman, 2016). As security has become more of an issue, there have been more presentations and security-oriented developments. On August 4, 2011 Jerome Radcliffe presented at Black Hat a compromise for an insulin pump. As a diabetic, he was acutely aware of. Radcliffe was able to reverse engineer the communication protocols. With this protocol in hand, he was able to access the pump and control it (Burns, Johnson, & Honeyman, 2016). On October 17, 2012, Barnaby Jack presented a video at the Ruxcon Breakpoint Security Conference showing the method to direct a pacemaker to deliver a shock using the serial and model number.
            A recent example of the effect from a lack of security was with Johnson & Johnson. In 3Q2016, Johnson & Johnson informed 14k doctors and diabetic patients of three vulnerabilities in their Animus insulin pumps. These and many more examples abound as security is not applied to these.
            In 2013, Barnaby Jack was supposed to present a compromise on a pacemaker at a hacker conference in Las Vegas. He passed on the evening prior.
Normal Process
            As with piece of equipment there is a standard process for the device to work. Millions of people depend on the devices across the globe (Wadhwa, 2012). As this is the case, the tolerances and parameters have to be narrowly construed. Most pacemakers have their data retrieved and settings configured via a wand or other device being placed proximate to the pacemaker. This may be relatively close or within a few feet of the device. The apparatus retrieves the data and makes adjustments to the sensors, thresholds, and rates (Lyle, 2015).
            This remote access is significantly beneficial. The patient can’t have a USB through their chest wall and skin. This also allows for simple adjustments. This is a simple way to collect data used by doctors and medical to aid the patients (Knapton, 2014). If there were need to be adjustments to the equipment, this may be done over-the-air (OTA) (Wadhwa, 2012).
Worst Case Scenario
            Anytime there is a death or disability, this is not the optimal situation and a shame. Many people have pacemakers and defibrillators through society. These persons work as mechanics, teachers, professors, CEOs, CFOs, diplomats, dignitaries, Presidential Cabinet members, and nation leaders.
            In a case shown in a recent dramatized television program, a political figure has the pacemaker/defibrillator implanted. The person is arriving for a meeting. Another group would prefer the person with the implanted device not to be using oxygen anymore. If it were to be possible to compromise the pacemaker, by extension it would be possible to assist the person with their transition. Although this is a simple case and application, this scenario could upgraded to a Secretary of State.
Regulation
“I have no problem with science…I just wish that it would give the law time to catch up.”
~Law & Order-Seed; 2/15/95, S5 E15
            It is difficult at best to couple InfoSec with the law. The wheels of justice and law move incredibly slow. Most legislators have minimal ideas of what is going on with InfoSec other than the sound bites and headlines. There also has tended to be a rather firm process in place to enact legislation, which is exceptionally unfriendly to change.
            In comparison, the InfoSec community moves rather quickly. This seems to change daily. There, procedurally with the process in place, is no way for the legal system to keep pace. This is unfortunately the reality.
            The FTC has attempted to start the legal process. There were generic proposals in 2013 (Armstrong, Kleidermacher, Klonoff, & Slepian, 2016). When a business engineers an IoT device, this should implement a suitable level of security. Per this endeavor, the data collected should be minimal, the data retained should be minimal, and other measures. This is weak, but a start.
Applicable to Other Equipment
            This issue is not limited to pacemakers. This also is completely applicable to most other connected medical device. The manufacturers need to understand not only the intended processes with the equipment, but also the hazards and potential harm with a lack of security being applied. The manufacturers need to define these risks with the system and put controls in place (Wu & Eagles, 2016). This risk analysis should complete a risk analysis based on the applicable standards.
            As a secondary point, to mitigate these issues the manufacture needs to review the controls related to the technical side of the product. This team effort of review and implementation would produce a document. This would involve applying the appropriate form and level of governance (Williams & Woodward, 2015). To have the optimal situation, this step would need to be proactive.
            There are several real-world examples of this. In 2016, Johnson & Johnson informed their clients of vulnerabilities. A model of their insulin pumps exhibited a vulnerability which would allow access to the insulin pump. In theory, an unauthorized party could direct the insulin pump to input a fatal dose of insulin. The vulnerable model was the Animas One Touch Ping. The distinct vulnerability was partially due to the equipment being connected (Harper, 2017).
            In 2015, there was an issue with the Hospira Sybiq infusion pump. The vulnerability here also allowed an unauthorized access. This however was through the hospital’s network (Harper, 2017). Lastly, in 2013, Barnaby Jack was to give a presentation on the methodology to compromise a pacemaker at a security conference in Las Vegas. The attack could take place up to 50 feet away. He passed on the night before the presentation (Harper, 2017).
St. Jude Medical (SJM) Lawsuit
            As a rule of thumb, a lawsuit is the last stage of the confrontation. Once this is filed, the situation becomes rather expansive in terms of finances, and funding. Most entities would have worked with SJM (Dark Reading, 2016). In the past, however, SJM brushed off attempts to fix the issues and patch management. MedSec elected to work with Muddy Waters in disclosing the issues (Dark Reading, 2016). MedSec stated the pacemaker and defibrillator could be compromised and manipulated (Pierson & Finkle, 2016) via the equipment vulnerabilities (Osborne, 2016). MedSec also stated that SJM should recall its pacemakers as these were vulnerable to attack (Tucker, 2016). These vulnerabilities were relative to the pacemaker and defibrillator were detailed in the report. (Nichols, 2010). These were rather significant (News-checker, 2016).This would allow the pacemaker to malfunction (Tucker, 2016).
            SJM sued Muddy Waters Consulting LLC, Muddy Waters Capital LLC, MedSec Holdings, Ltd., MedSec LLC, and the three persons who were principals in the businesses (Business Wire, 2016; Dark Reading, 2016; Tucker, 2016). The matter was filed in the USDC for the District of Minnesota as the St. Jude Medical v. Muddy Waters, MedSec Holdings, et al. with case number 16-cv-0302 (Pierson & Finkle, 2016). The full filing may be viewed at https://regmedia.co.uk/2016/09/08/medsec_lawsuit.pdf.
            The claimed cause of action was the defendants defamed SJD with false information (Dark Reading, 2016) and intended to be malicious (Pierson & Finkle, 2016). SJM stated these were false warnings (Osborne, 2016). In particular, the cause of action were the false statements, false advertising, conspiracy, and manipulation of the public market (Business Wire, 2016; Tucker, 2016). In short, SJM sued MedSec, et al. to correct the alleged false information that had been provided to the media (Osborne, 2016).
            As a result of the disclosures and/or the lawsuit, the SJM shares decreased significantly (Dark Reading, 2016). The stock share price was lowered an estimated 10% during the day and rebounded so the net effect was only an estimated decrease of 3% (Pierson & Finkle, 2016). SJM claimed the attackers only did this to provide a profit to the firm (Kan, 2016).
            SJM had a rather distinct focus on the MedSec and Muddy Waters groups. SJM claimed the research and investment firms were false (Nichols, 2016), had applied flawed testing methods, used outdated software, and simply did not understand the medical device technology (Osborne, 2016; Kan, 2016).   SJM stated MedSec’s claims were made-up (Nichols, 2016). SJM went as far as to retain the University of Michigan to attempt to replicate the study. The UM research team arrived as a different result. The research team at UM stated MedSec’s research was flawed and UM could find no evidence to support the claims (Tucker, 2016; Newmarker, 2016).
            MedSec’s defense was rather simple. The disclosure was correct (Dark Reading, 2016) and the University of Michigan research team was wrong. Arising from this set of issues was a class action lawsuit against SJM (Daniels, 2016). The cause of action for the class action lawsuit was a failure to adequately secure the equipment with the remote tracking function (Daniels, 2016).
Insecurity
            No product is 100% perfect. A dedicated set of engineers collaborating with the InfoSec staff have the opportunity to create a product that has the appropriate safety and security features built in. There are other instances however when this is not the case and the security is not appropriately applied. This is especially an issue when the device is attached to a person via being implanted (Wadhwa, 2012) and a connected device, as the results from an attack may be deadly (Knapton, 2014).
            These connected devices have been known to be insecure by the industry and manufacturers. The manufacturers have not overall been working diligently to secure these. A few distinct manufacturers also have declared their devices are perfectly safe to the public. The primary attack point has been the wireless communication. This acts to regulate the devices assisting the human heart to function properly (Knapton, 2014). This is an area of vulnerability to be exploited. The manufacturers simply have not been prepared (Wadhwa, 2012) and security not integrated (Zorz, 2016).
            The lack of security has even gathered the attention of the U.S. Department of Homeland Security (DHS). In 2014 the DHS began to investigate more than 20 medical devices (Knapton, 2014). In 2013, the DHS Industrial Control Systems Cyber Emergency Response Team (OCS-CERT) noted approximately 300 devices manufactured by 40 companies (Knapton, 2014). The examples for the  vulnerabilities abound. Each manufacturer and product line has the potential for vulnerabilities. These have exhibited insecure architecture, hard-coded passwords that were not able to be changed, and other insecure protocols. As for the passwords, this would allow an unauthorized third party to access the machine (Knapton, 2014).
MedSec
               In pacemakers alone, there has been noted more than 8,000 vulnerabilities in the program code (Vaas, 2017). This sample was from four manufacturers. This number does not represent a majority of the manufacturers present in the market.
               This also applies to the MedSec issues. The vulnerabilities were blatantly present, yet not acted on by SJM. The security was so poor that the FDA threatened legal action against SJM if these vulnerabilities were not addressed. This was significant to the extent the FDA and DHS both issued a notice or warning letter of these insecurities (Uchill, 2017). SJM, on the same day as the notice, noted these were “extremely low cyber-security risks” (Vaas, 2017). MedSec did push the patches for this set of issues (Carlson, 2017).
               There were a number of vulnerabilities with the pacemaker product. These included:
·        A lack of strong authentication (Daniels, 2016).
·        Commands may be issued from a distance.
·        SJM included a code which could be used for the purpose of over-riding. This was a fixed 3byte code.
·        The communications channel between the endpoints (pacemaker and the Merlin@home base unit) was weak (Vaas, 2017; Brenner, 2017; Daniels, 2016).
·        A 3-byte back door was left open.
·        Poor level of encryption.
·        The anti-debugging tools were weak.
In Closing…
               Medical devices are pertinent to our lives and will continue to grow in usage and visibility. These should not be treated as just another piece of equipment, but as a device that has to be secured. Without this security, adequately and appropriately in place, the potential for compromises will be there, waiting to be implemented.

References and Resources
Ahmadi, M. (2017). FDA and medical industry fear ware of medical-device hacks. Retrieved from http://www.informationsecuritybuzz.com/expert-comments/fda-medical-industry-fear-wave-medical-device-hacks/
Armstrong, D.G., Kleidermacher, D.N., Klonoff, D.C., & Slepian, M.J. (2015). Cybersecurity regulation of wisdom devices for performance and assurance in the age of “medjacking”. Journal of Diabetes Science and Technology, 10(2), 435-438. doi:10.1177/1932296815602100
BBC. (2016). Medical device cyber-safety rules issued by US watchdog. Retrieved from http://www.bbc.com/news/technology-38458864
Bethell, M. (2016, October 19). Cyber hackers threatens security of lifesaving medical devices. Retrieved from http://www.dailytech.com/Cyber+Hack+Threaten+Security+of+Lifesaving+Medical+Devices+/article37716.htm
Brenner, B. (2017, January 23). St. Jude case highlights ongoing divide over ‘responsible bugs disclosure’. Retrieved from https://nakedsecurity.sophos.com/2017/01/23/st-jude-case-highlights-ongoing-divide-over-responsible-bugs-disclosure
Burns, A.J., Johnson, M.E., & Honeyman, P. (2016). A brief chronology of medical device security. Communications of the ACM, 59(10), 66-72. doi:10.1145/2890488. Retrieved from http://cacm.acm.org/magazine/2016/10/207766-a-brief-chronology-of-medical-device-security/fulltext
Business Wire. (2016, September 7). St. jude medical brings legal action against muddy waters and medsec. Retrieved from http://www.nasdaq.com/press-release/st-jude-medical-brings-legal-action-against-muddy-waters-and-medsec-20160907/00282
Business Wire. (2017, January 9). St. jude medical announces cybersecurity updates. Retrieved from http://www.businesswire.com/news/home/20170109005921/en/st.-jude-medical-announces-cybersecurity-updates
Carlson, J. (2017, January 10). FDA says st. jude heart devices vulnerable to hacking. Retrieved from http://www.startribune.com/fda-says-st-jude-heart-devices-vulnerable-to-hacking/410153595/ 
Castellucci, M. (2016, October 18). St. jude medical steps up cybersecurity measures after questions about device safety. Retrieved from http://www.modernhealthcare.com/article/20161018/NEWS/161019901
CBS News. (2017, January 10). U.S. warns of security flaw that could allow hackers control of heart devices. Retrieved from http://www.cbsnews.com/news/cybersecurity-flaw-that-could-allow-hackers-control-of-heart-devices-united-states-warns/
Center for Devices and Radiological Health. (2002, January 11). General principles of software validation; Final guidance for industry and FDA staff. Retrieved from http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM085281.html
Centerwatch. (2016, Septembe 12). St. jude medical sues muddy waters and medsec. Retrieved from https://www.centerwatch.com/news-online/2016/09/21/st-jude-medical-sues-muddy-waters-medsec/
Cherry, S. (2013, April 30). Hacking pacemakers. Retrieved from http://spectrum.ieee.org/podcast/biomedical/devices/hacking-pacemakers
Claburn, T. (2008, March 12). Three medical schools demonstrate the wireless dangers that can disturb an implantable cardioverter defibrillator like the medtronic maximo DR. Retrieved from http://www.informationweek.com/pacemakers-vulnerable-to-hacking/d/d-id/1065618
Cloud Security Alliance. (2016, October 6). HIPAA violations examples and cases-Eight cautionary tales. Retrieved from https://blog.cloudsecurityalliance.org/2016/10/06/hipaa-vioations-examples-cases-eight-cautionary-tales/
Cluley, G. (2016, December 1). Under attack: How hackers could remotely target your pacemaker. Retrieved from https://www.tripwire.com/state-of-security/featured/under-atack-how-hackers-could-remotely-target-your-pacemaker/#
Cluley, G. (2017, January 10). Security scare over hackable heart implants. Retrieved from http://www.welivesecurity.com/2017/01/10/security-scare-hackable-heart-implants/
Daniels, M. (2016, August 29). St. jude heart devices have security weaknesses, suit says. Retrieved form http://www.law360.com/articles/833622/st-jude-heart-devices-have-security-weakness-suit-says
Dark Reading Staff. (2016, September 7). Medical device vulnerability-Disclosure flap intensifies. Retrieved from http://www.darkreading.com/vulnerabilities-threats/st-jude-sues-muddy-waters-medec/d/d-id/1326837
Data Breach Today. (2016, January 18). FDA issues more medical device security guidance. Retrieved from http://www.databreachtoday.com/fda-issues-more-medical-device-security-guidance-a-8805
Dellinger, A.J. (2017, May 30). Medical device makers expect attacks within the next year, but aren’t prepared. Retrieved from http://newsweek.com/medical-device-safety-can-they-be-hacked-companies-manufacturers-concerned-617507
Densford, F. (2017, January 9). St. jude releases FDA-cleared merlin@home cybersecurity update. Retrieved from http://www.massdevice.com/st-jude-releases-fda-cleared-merlinhome-cybersecurity-update/
FDA. (2016). Cybersecurity. Retrieved from http://www.fda.gov/MedicalDevices/DigitalHealth/UCM373213.htm
Finkle, J. (2017, January 9). St. jude heart devices get cyber security updates after probe into hack vulnerability. Retrieved from http://www.huffingtonpost.com/entry/st-jude-heart-devices-get-cyber-security-updates-after-probe-into-hack-vulnerability_us_5873d482e4b099cdb0fea482
Halperin, D., Heydt-Benjamin, T.S., Ransford, B., Clark, S.S., Defend, B., Morgan, W., Fu, K., Kohno, T., & Maisel, W. (2008). Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses. 2008 IEEE Symposium on Security and Privacy, 1-14. Retrieved from http://www.secure-medicin.org/public/publications/icd-study.pdf
Harper, C. (2017, April 10). FDA, industry fear wave of medical-device hacks. Retrieved from http://thehill.com/policy/healthcare/328120-fda-industry-fear-wave-of-medical-device-hacks
Hatmaker, T. (2016, December 28). FDA issues new security guidelines so that your pacemaker won’t get hacked. Retrieved from https://techcrunch.com/2016/12/28/fda-issues-new-security-guidance-so-that-your-pacemaker-wont-get-hacked/
Help Net Security. (2016, October 19). Securing medical devices: Cybersecurity spending to triple by 2021. Retrieved from https://www.helpnetsecurity.com/2016/10/19/securing-medical-devices/
HIMSS. (2013). Medical device security. Retrieved from http://www.himss.org/medical-device-security
Ismail, N. (2017, April 3). IoT to improve the programming of implantable devices. Retrieved from http://www.information-age.com/iot-impreve-programming-implantable-devices-123465487/
Ismail, N. (2017, April 11). Medical devices at severe risk of hack attacks. Retrieved from http://www.information-age.com/medical-devices-severe-risk-hack-attacks-123465684
Kan, M. (2016, August 29). Medical device security disclosure ignites an ethics firestorm. Retrieved from http://www.computerworld.com/article/3113385/security/medical-device-security-ignites-an-ethics-firestorm.html
Khandelwal, S. (2017, June 5). Over 8,600 vulnerabilities found in pacemakers. Retrieved from http://thehackernews.com/2017/06/pacemaker-vulnerability.html
Knapton, S. (2014, November 6). Terrorists could hack pacemakers like in homeland, say security experts. Retrieved from http://www.telegraph.co.uk/news/science/science-news/11212777/Terrorists-could-hack-pacemakers-like-in-homeland-say-security-experts.html
Kohgadai, A. (2016, October 6). HIPAA violations examples and case-Eight cautionary tales. Retrieved from https://blog.cloudsecurityalliance.org/2016/10/06/hipaa-violations-examples-cases-eight-cautionary-tales/
Jones, D., & Rushing, S. (2016). HIPAA compliance-not just an issue for healthcare providers. Retrieved form http://www.jdsupra.com/legalnews/hipaa-compliance-not-just-an-issue-for-31185/
Lemos, R. (2017, May 18). Embedded windows medical ‘devices’ infected by wannacry ransomware. Retrieved from http://www.eweek.com/security/embedded-windows-medical-devices-infected-by-wannacry-ransomware
Lyle, D.P. (2015, January 14). Hacking pacemakers for murder no longer the perfect crime. Retrieved from https://writersforensicsblog.wordpress.com/2015/01/14/hacking-pacemaker-for-murder-no-longer-the-perfect-crime/
Marin, E., Singelee, D., Garcia, F.D., Chothia, T., Willems, R., & Preneel, B. (2016). On the (in)security of the latest generations implantable cardiac defibrillators and how to secure them. ACSAC. doi:http://dx.doi.org/10.1145/2991079.2991094
McGee, M.K. (2016). FDA issues more medical device security guidance. Retrieved from http://www.databreachtoday.com/fda-issues-more-medical-device-security-guidance-a-8805
Moon, M. (2016, December 28). FDA issues final guidance on medical devices’ cybersecurity. Retrieved from https://www.engadget.com/2016/12/28/fda-medical-devices-cyber-security-final-guidance/
Muddy Waters Capital LLC. (2016, August 25). Muddy waters research. Retrieved from http://d.muddywatersresearch.com/wp-content/uploads/2016/08/MW_STJP_08252016_2.pdf
Newmarker, C. (2016, September 7). St. jude sues over cybersecurity accusations. Retrieved from http://www.qmed.com/mpmn/medtechpulse/st-jude-sues-over-cybersecurity-accusations
Nichols, S. (2016, September 7). St. jude sues short-selling MedSec over pacemaker hack report. Retrieved from http://www.theregister.co.uk/2016/09/07/st_jude_sues_over_hacking-claim/
Osborne, C. (2016, September, 8). MedSec sued over st. jude pacemaker vulnerability report. Retrieved from http://www.zdnet.com/article/medsec-sued-over-st-jude-pacemaker-vulnerability-report
Pierson, R., & Finkle, J. (2016, September 7). St. jude sues short-seller over heart device allegations. Retrieved from http://whtc.com/news/articles/2016/sep/07/st-jude-sues-muddy-waters-medsec-over-heart-device-allegations/
Regmedia. (2016, September 8). St. Jude Medical, Inc. vs. Muddy Waters Consulting, et al. Retrieved from https://regmedia.co.uk/2016/09/08/medsec_lawsuit.pdf
Sayer, P. (2016, December 1). Implantable medical devices can be hacked to harm patients. Retrieved from http://www.computerworld.com/article/3146215/security/implantable-medical-devices-can-be-hacked-to-harm-patients.html
Snell, E. (n.d.). How ransomware affects hospital data security. Retrieved from http://healthitsecurity.com/features/how-ransomware-affects-hospital-data-security/
Slabodkin, G. (2017, February 22). Ransomware emerging as medical devices cybersecurity threat. Retrieved from https://www.information-management.com/news/
Sorrel, C. (2008, March 12). Scientists demonstrate deadly wifi pacemaker hack. Retrieved from https://www.wired.com/2008/03/scientists-demo/
Spring, T. (2016, October 24). St. jude faces new claim heart implants are hackable. Retrieved from https://threatpost.com/st-jude-faces-new-claim-heart-implants-are-hackable/121504/
Stanford, J. (2017, June 12). Hacking a heart pacemaker isn’t science fiction. See what experts are doing to prevent it. Retrieved from http://www.azcentral.com/story/news/local/phoenix/2017/06/12/hacking-pacemaker-isn’t-science-fiction-movie-plotlline-but-reality/378176001
Storm, D. (2015, September 8). Researchers hack a pacemaker, kill a man (nequin). Retrieved from http://www.computerworld.com/article/2981527/cybercrime-hacking/researchers-hack-a-pacemaker-kill-a-man-nequin.html
St. Jude Medical. (2016, September 7). St. jude medical brings legal action against muddy waters and medsec. Retrieved from http://media.sjm.com/newsroom/news-releases/news-releases-details/2016/St-Jude-Medical-Brings-Legal-Action-Against-Muddy-Waters-and-MedSec/default.aspx
Sullivan, C. (2016, October 6). How to mitigate data breaches in health IT. Retrieved from http://www.information-management.com/news/security/how-to-mitigate-data-breaches-in-health-it-100299441.html
Sun, L.H., & Dennis, B. (2013, June 13). FDA, facing cybersecurity threats, tightens medical-device standards. The Washington Post.
Thompson, J. (2016, October 27). It is shocking! Even heart devices can be hacked. Retrieved from http://www.newseveryday.com/articles/50840/20161027/it-is-shocking-even-heart-devices-can-be-hacked.htm
Tucker, A. (2016, September 7). St. jude medical filed a lawsuit against MedSec and muddy waters. Retrieved from http://www.legalreader.com/st-jude-medical-files-lawsuit-against-medsec-and-muddy-waters/
Uchill, J. (2017, April 13). FDA threatens action against medical device-maker over poor cybersecurity. Retrieved from http://thehill.com/policy/cybersecurity/328752-fda-threatens-st-jude-medical-device-over-poor-cybersecurity
U.S. Department of Health and Human Services. (2002, January 11). General principles of software validation; Final guidance for industry and FDA staff. Retrieved from http://www.fda.gov/MedialDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.html
Vaas, L. (2017, January 12). Pacemakers patched against potentially life threatening hacks. Retrieved from https://nakedsecurity.sophos.com/017/01/12/pacemakers-patched-against-potentially-lifethreatening-hacks/
Vaas, L. (2016, May 30). Security of medical devices ‘is a life or death issue’, warns researcher. Retrieved from https://naked security.sophos.com/2017/05/30/security-of-medical-devices-is-a-life-or-death-issue-warns-researcher/
Wadhwa, T. (2012, December 6). Yes, you can hack a pacemaker (and other medical devices too). Retrieved from http://www.forbes.com/sites/singularity/2012/12/06/yes-you-can-hack-a-pacemaker-and-other-medical-devices-too/#52bd766613e0
White, J. (2015, October 5). Why medical device security should be top priority. Retrieved from http://www.healthcarebusinesstech.com/medical-device-security/
Williams, P.A., & Woodward, A.J. (2015). Cybersecurity vulnerabilities in medical devices: A complex environment and multi-faceted problem. Medical Devices: Evidence and Research, 8, 305-316. doi:10.2147:MDER.S50048
Wolf, D., Chernuch, M.S., Diamond, J. (writers), & Scardino, D. (producer). (1995). Law & order-Seed. (S5 E15). Law & Order. Atlanta, GA: TNT.
Wu, F., & Eagles, S. (2016). Cybersecurity for medical device manufacturers: Ensuing safety and functionality. Biomedical Instrumentation & Technology, 50(1), 23-34.
Zorz, Z. (2016, December 1). Insecure pacemakers can be easily hacked. Retrieved from https://www.helpnetsecurity.com/2016/12/01/insecure-pacemakers-easily-hacked/
Zorz, Z. (2017, January 12). FDA urges patients to implement patch to secure their cardiac implants. FDA urges patients to implement patch to secure their cardiac implants. Retrieved from https://www.helpnetsecurity.com/2017/01/12/secure-cardiac-implants/

Insecure Hardware is a Global Issue

            Insecure hardware is a massive issue for many parties. The insecure affects not only the individual or business as they use computers in the home and office, but also the internet as a whole. This is an issue for the equipment and the engineers responsible for the development of the equipment. For the equipment owner, they could now have as one of their assets compromised piece of equipment. This would be connected to the network and possibly other systems in the business or home. The equipment may be used for the normal, intended purpose (e.g. payroll, accounts receivable, and other vital functions). This may also be used for nefarious purposes at the same time, unbeknownst to the owner.
            This may sound prima facie a bit far-fetched, evoking the thought for the consumer of “This would not happen to me.” What would anyone want with an IP camera or route from a grandma in Nebraska? The focus would be potential unauthorized usage by the persons or people who code bots to leverage the capabilities of these to attack other systems. These attacks have been with the purpose of securing more IoT devices to build the bot army, which would then be directed at their target. In the last year there have been too many examples of this. There have been massive DDoS attacks on Krebs on Security and Deutsche Telekom, as two well-known examples. These and many more represent the significant DDoS attacks by Mirai and Persirai malware, among others.
            The insecure equipment has turned into a potential malware tool for their targets when executed. The consumers as a whole and the IT industry would hope this would be a minor idea, not generally in use, and not affecting many units. Unfortunately, this is not the case. This continues to be an issue as more of these insecure assets are compromised and used as part of the bot army.
            This issue is global in nature and effect. The scope is by far not limited to the US. The products, regardless of where they are made, and manufactured and sent across the globe, insecure and all. The remediation for this is relatively simple, but taxing in its application. The equipment needs to have more security features in place. Also any default passwords should be required to be changed. These small steps would remove much of the security issues with this.


Bug bounty programs: Slots difficult to fill

            The need for bug bounty programs began years ago as a void formed. The manufacturers were producing their goods and services, as to be expected. An issue experienced was the manufacturers had the “first to market” mentality in place. There was and continues to be in certain markets, a hurry to design, engineer, and manufacture the product. The product needs to be the first in the marketplace for the consumer to purchase the unit. In theory, the manufacturer would be the market leader, and sell the maximum number of units and gain the market share. If the manufacturer were to wait, they would not be maximizing the sales volume and would be trying to catch up with their peers. This sales process methodology is unfortunately still prevalent. As of late this has been noted with routers, IP cameras, and other like equipment.
With these and other products security architecture was applied in various levels. This ranged from very little, with too many of the IoT products, to a moderate level of security applied. A contributing factor to this has been the lack of information security talent. This is a function of the limited number of programs focused on this, newer programs not coming online at a quick enough pace, and a time lag once these are in place of at least three years prior to graduates entering the workforce.
One area growing in importance is vehicle security. The number of vehicles with embedded systems continues to grow. The autonomous vehicles are actively being tested on the roads used by other people presently. These vehicles are expected to be in full production within five years. These systems are being developed with the focus of having them operational in a timely manner with security being a secondary focus.
With the growing need for information security (InfoSec) professionals, there is an issue. In this specialty, there is a limited number of people that have the knowledge and expertise to attack the embedded systems in a vehicle. Most firms in this specialty do not allow their personnel to contribute to these bug bounty programs (Gray, 2017). This appears to be starting to relax, but is still a parameter to overcome.
With a bug bounty program, the sponsoring firm is able to add to their baseline of security. With vehicles, there are ample areas to research. The connected and autonomous vehicles in use today tend to be more computers on wheels than anything. From an administrative side, a bug bounty program is easier with a vehicle that has been sold for years. This allows for more vehicles and modules to be tested, as there are more vehicles on the lots and junkyards. With the new vehicles an issue could be, dependent on the circumstances, the cost. The new vehicles cost upwards of $30k new. The internal client may not want to part with two or three vehicles due to this constraint on their budget. With the junkyard vehicles, these may not have all the original equipment due to an accident or other force, however many of the modules would be intact and perfectly testable.
There is much to do with InfoSec and vehicles. This subfield of InfoSec is growing by leaps and bounds. More of the manufacturers are producing more connected vehicles, applications, and hardware. The bug bounty programs are a welcome addition to the InfoSec environment for those manufacturers that without an internal testing program. This has and will continue to provide knowledge re: the vulnerabilities that may not normally be found.

Reference
Gray, P. (2017, July 2). Biz soap box: Bugcrowd founder and CEO casey ellis on the future of crowd sourced security. Retrieved from https://risky.biz/


BlueBorne: Uh oh.


            Bluetooth has been in use in the public for well over a decade. Previous attacks focused on the insecurity of the Bluetooth protocol. The new attack, BlueBorne, is unique in its approach for this time junction.
            This attack is rather substantial in its potential reach for targets. This may affect anywhere from 5.3B (Khandelwal, 2017; Moscaritolo, 2017) to 8.2B devices worldwide (Zorz, 2017) with iOS, Android, Windows, and Linux OS devices with Bluetooth enabled. This is due to its agnostic focus on the Bluetooth process itself, in comparison to the various platforms.
            The user does not have to be a victim of malware for the attack to be successful. The user does not have to download a file or link, click anything, or do anything to be a victim. The only prerequisite is for the Bluetooth to be enabled and on (Zorz, 2017; Khandelwal, 2017; Rascal23, 2017) and proximate to the attacker (Khandelwal, 2017). This distance would need to be less than 32 feet (Goodin, 2017). The device does not have to be paired with any other device (Moscaritolo, 2017), inclusive of the attacker’s device. This enables the attack to be silent as it affects the device. This design does not “wake up” the targeted device (Biggs, 2017) and the user does not suspect the device is compromised. The speed of the attack also is innovative. For the device to be compromised in its entirety takes only up to 10 seconds for the process, inclusive of the choices the malware has to complete (Goodin, 2017).
            This attack gives the attacker a choice of avenues to pursue in compromising the device. The attacker may take complete control of the device, continue on the course of spreading the malware further, or in the alternative establish a man-in-the-middle attack (MitM) (Khandelwal, 2017). As an off-shoot of this, the attacker could in theory create a botnet network from these. This further infection of other devices proximate to the infected on likewise could be accomplished in seconds (Rascal23, 2017).
            This also is a valid attack against air-gapped machines that were previously thought to be secure. As with this target, all that has to happen is the Bluetooth is on and the attacker is proximate.
            The reports form the researchers who detected the attack (Armis Labs) are available at http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf and https://www.armis.com/blueborne/.
Affected Devices
            There are millions of unpatched mobile phones, computers, and internet of things (IoT) devices. As these are not patched, the attacker would have the capability to exploit the vulnerability to control the devices (US-CERT, 2017). This is specifically addressed with VU#240311.
            The affected devices are:
a)      Samsung Smart Watch, TVs, and Refrigerators,
b)     Samsung Galaxy Phones and Tablets,
c)      Google Pixel Smartphone,
d)     All Windows Computers Beginning with Vista,
e)      All iPhone, iPod, and iPod touch devices with iOS 9.3.5 and previous versions, and
f)      Pumpkin Car Audio System (Zorz, 2017).
Of these attacks, the strongest attack involves the Android and Linux OS devices. With these, the Bluetooth implementation are vulnerable to memory corruption exploit anyway. The attack allows the malware to run with high system privilege. This gives the exploit access to the sensitive system resources (Goodin, 2017).   
            The Linux devices don’t utilize address space layout randomization (ASLR) or a like security feature to mitigate the BlueBorne’s potential buffer overflow vulnerability. The Android does use the ASLR, however the attack is able to bypass the security feature with another vulnerability being exploited that leaks memory location where key processes are operating (Goodin, 2017). In addition, the malware does attack the hosts L2CAP (logical link and adaption layer protocol) at the stack data layer. The L2CAP supports the connection multiplexing, segmentation, and re-assembly of packets for upper layer protocols.
US-CERT
            BlueBorne has eight vulnerabilities associated with it through the various OSs (KB, 2017; Zorz, 2017; Biggs, 2017; Goodin, 2017; Khandelwal, 2017).
a)      CVE-2017-1000251 (CWE-120)
a.      Buffer copy without checking the size of the input (“Classic Buffer Overflow”)
b.      Linux Kernel version 3.3-rc1 is affected. This was coded to exploit a vulnerable implementation of L2CAP EFS in BlueZ. The I2cap_parse_conf_rsp was not coded to check the rsp argument length prior to unpacking. This allows the attack to overflow the 64 byte bugger on the kernel stack with an unlimited amount of data.
b)     CVE-2017-0785 (CWE-125)
a.      Out of bounds read
b.      There is a vulnerable implementation of SDP. The attacker could exert control over the device. This would take the form of controlling the continuation state within SDP, request packets and cause the SDP server to return an out of bounds read from the response buffer.
c)      CVE-2017-0785 (CWE-125)
a.      Out of bounds read
b.      This affects all versions of Android prior to September 9, 2017. The vulnerability contains a vulnerable implementation of SDP within the Android Bluetooth software stack. An attacker may be able to control the continuation state within the SDP request packets and cause the SDP server to return an out of bounds read from the response buffer. This is much like CVE-2017-1000250, however this is directed at a different stack.
d)     CVE-2017-0781 (CWE-122)
a.      This CVE is a heap based buffer overflow which affects all Android versions prior to September 9, 2017.  With this, an incorrect buffer size is passed to a memcpy call within the BVEP implementation for Android. This may allow the attacker to send crafted packets to the device that would overflow the heap.
e)      CVE-2017-0782 (CWE-191)
a.      Integer Underflow (Wrap or Wraparound)
b.      This CVE focusses on the BNCP implementation for Android. Here the rem_len does not check the size and is applicable to all versions prior to September 9, 2017. This allows for an integer underflow and further unsafe processing of attacker controlled packets.
f)      CVE-2017-14315 (CWE-122)
a.      This affects Apple’s Bluetooth Low-Energy Audio Protocol (LEAP) implementation in iOS version 9.3.5 and lower, Apple TV tv OS version 7.2.2 and lower. This does not property validate the CID for incoming Bluetooth LEAP audio data. This may result in a heap overflow due to this vulnerability not properly validating the packet sizes prior to calling memcpy.
g)     CVE-2017-0783 and CVE-2017-8628 (CWE-300)
a.      With this vulnerability there are security level requirements that  are not correct in the PAN profile in the Bluetooth implementation. This may allow an attacker to secure permission to perform a man-in-the-middle (MitM) attack.
With these vulnerabilities, four are critical and should be addressed first.
Solutions
            The affected devices should download and apply the patches to resolve the issue immediately. As noted, the patches are readily available for Windows, iOS, Linux kernel, and Android (KB, 2017). Google pushed its patches with their September Android update. This was for Marshmallow and Nougat (KB, 2017). Microsoft pushed its patches on September 12. Apple mitigated the vulnerability with its iOS 10. Linux should provide their mitigation soon.
There may be an issue with the Android devices in case when the Android partners have do not immediately pass the patch onto their clients. Until this occurs, the Bluetooth should be turned off until this is implemented (KB, 2017; Zorz, 2017).

References
Biggs, J. (2017, September 13). New Bluetooth vulnerability can hack a phone in 10 seconds. Retrieved from https://techcrunch.com/2017/09/12/new-bluetooth-vulnerability-can-hack-a-phone-in-ten-seconds/?ncid=rss
Goodin, D. (2017, September 12). Billions of devices imperiled by new clickless Bluetooth attack. Retrieved from https://arstechnica.com/information-technology/2017/09/bluetooth-bugs-open-billions-of-devices-to-attacks-no-clicking-required/
KB. (2017, September 12). Vulnerability note VU#240311: Multiple Bluetooth implementation vulnerabilities affect many devices. Retrieved from http://www.kb.cert.org/vulns/id/240311
Khandelwal, S. (2017, September 12). Blueborne: Critical Bluetooth attack puts billions of devices at risk of hacking. Retrieved from http://thehackernews.com/2017/09/blueborne-bluetooth-hacking.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+TheHackerNews+...
Moscaritolo, A. (2017, September 13). BlueBorne Bluetooth attack puts 5 billion devices at risk. Retrieved from https://www.pcmag.com/news/356174/blueborne-bluetooth-attack-puts-5-billion-devices-at-risk
Rascal23. (2017, September 13). Linux gets blasted by blueborne too. Retrieved from http://fullcirclemagazine.org/2017/09/13/linux-gets-blasted-by-blueborne-too/
US-CERT. (2017, September 12). Blue Borne Bluetooth vulnerabilities. Retrieved from https://www.us-cert.gov/ncas/current-activity/2017/09/12/BlueBorne-Bluetooth-Vulnerabilities
Zorz, Z. (2017, September 13). Billions of Bluetooth-enabled devices vulnerable to new airborne attacks. Retrieved from https://www.helpnetsecurity.com/2017/09/13/blueborne/


Be Careful What You Share on Social Media

            People are focused on posting their daily lives on the various social media sites. This may include vacation photos and updates, birthday parties, sporting events, business trips, dinner parties, and virtually any other activity. The users do this without any reservation or concerns.
            The persons don’t appreciate the reach of the internet into their data. Unfortunately too many people don’t secure their social media accounts. Without this in place, other people, especially those who have no relevant business with the target, have access to the person’s private life. This includes the details of when they went on vacation, who they went with, where they stayed, activities while there, etc. With the proper level of security applied, the issues associated with this would be mitigated.
One issue with this involves identity theft. There are clear risks with sharing too much personal information with the public and friends. This data, which may be readily available, is able to be used by attackers to gain leverage on the person/target. As an example, with the prior noted information, the attacker could work towards impersonating the user with various vendors that work with the person/target, such as the local bank. The attacker would start small and build on this in creating the background and gather private, confidential data for the person. As the attacker exfiltrates more information regarding the user, the basis of information grows and allows for a greater potential for the attacker to contact more organizations of greater value the user is in contact with to exfiltrate more data and assets. For example, there are certain organizations or departments that don’t allow a person access unless the full, thorough authentication process is in place and used. At some point in time, the attacker, when enough target data is secured, may take over the identity completely and move assets (retirement funds, cash, etc.) from the user.

A little information tends to be dangerous for the person securing this, while a great amount of information may be devastating for the target. Users need to think about what data and information they are actively putting on the internet in the social media sites, as this could prove to be a disaster for them for the future. 

Yes, logs are important

In recent history there have been rather extensive and significant breaches affecting millions of people. This action has provided criminals with a rather extensive amount of data to sell and resell on the darkweb. This has a rather substantial effect on the affected consumers. They have three options to deal with this. The consumers may do nothing and hope the criminals do absolutely nothing with the personal data. This is not the optimal situation and hardly could be recommended. The altterantive is an affirmative defense of freezing one's credit or contacting with a service to monitor their credit.

For the breached party, the consequence is a bit more serious, especially in the healthcare industry. Granted data was still exfiltrated, however in this case there are also healthcare records in addition to the usual records, inclusive of the  SSN. At this point, the HIPPA statute penalties may become an issue. On an alternative front, the entity may face civil lawsuits from the consumers. This, based on the number of the clients affected, may be millions of dollars.

A recent example of a breach gone really bad occurred with eClinicWorks, an electronic health records (EHR) vendor. There is presently a class action suit for nearly $1B based on the firm's software allegedly not being able to provide reliable health information for the patients. This directly would affect millions of patients. Effectually the patients have the "opportunity" to monitor their credit reports, health insurance reporting, and too many other data points to regularly monitor for abuse.

This was only a portion of the issue however. The firm also agreed to a $155M settlement and entered into a five-year corporate integrity agreement with the Department of Health and Human Services Office of the Inspector General.

These relatively serious legal proceedings were initiated after the business allegedly did not adhere to its claim of meeting the HTIECH Act EHR incentive program's certification requirement. Per the civil suit, the claim was the incorrect medical data was displayed, multiple patient's data shown at the same time, incorrect medical histories were displayed, and pertinent to the InfoSec field, the audit logs did not accurately record the user's actions, and other issues.

These deficiencies and oversights have led to a financial repercussion for the business, reputational risk, and potential loss of revenue for future time periods. Germane to the InfoSec industry is the log issue. With the lack of operational security stance, the logs are virtually useless and cannot be depended on. With these providing inaccurate user action logs, these would not be useful and be pointless.

Unfortunately, this is not an isolated case. Examples of poor coding and data flows are in the industry creating issues for business and the consumers.

Phishing: It's not what is for dinner

            Phishing has been in use in one form or another probably a week after the first email account was used by consumers. Phishing has become glaringly prevalent in today’s society. This clogs up the Spam folders daily across the U.S. The attackers have operationalized phishing as a vector to compromise the user’s information, data, email, credentials, and any other facet that has value. This has become so popular and used as much as it is due to the ease of application. The technical requirements for this are minor. The phisher has to create a moderately believable email generally without significant grammar or spelling errors, which is not difficult. This may involve a bank, sale at a retail business, sale on pharmaceuticals, or any other possible email that is appropriate.
            The more productive and revenue generating phishing scams or campaigns have involved ransomware or the executive wire scam. Most are familiar with the ransomware phishing exploit, as it has been in the news more frequently. With this the user opens a link or attachment that appears to be fine, however is actually malicious in nature. The system, network segment, network, etc. is encrypted. The attackers later offer to provide the decryption key…for a fee.
            The executive wire scam has predominantly taken the form of someone in accounting or finance receiving an email directing them to wire funds, varying per target from a few thousand to millions, dependent on the target, what was encrypted, the industry, etc. The usual email is rather demanding, stating the person has to wire the money in the next few hours, the executive sending the email is in a meeting or would not be accessible, and it is imperative that this be sent. These both are very low tech attacks, which work on the user’s oversight and willingness to do the job and keep the executive happy.
            All is not lost though. There are many options the users need to be aware of in order to limit the risk of this continuing to happen. For instance, the bank is not going to send the user a link in an email with a message directing the user to click on a link or to provide the credentials on the email. Generally, an invoice does not need to be paid within a few hours or a discount would be lost. As a rule of thumb, the discount period is a few weeks, not hours. Although pet pictures are wonderful, strangers are not going to email these to you. Users generally don’t purchase pharmaceuticals online from a firm they have never heard from and their workplace is not associated with.
            One tool that works wonders is simple communication. If an email arrives and demands a payment within a very short amount of time and the sending party directly, aggressively states that they are not accessible, simply check if they are actually on vacation, if they are in a meeting, send a quick email to the person while not replying to the email that was received for authentication, or just make a quick call. This only takes a moment and has the potential to save a large amount of money and embarrassment.