Killed by code – back to the future

Back in 2011, I thought it’s only a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device).

Fast forward to Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

  • Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

I’ve been talking to our medical device customers about mobile security of implanted devices for over 4 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 ago and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.  If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:

  • are intended to be used as an accessory to a regulated medical device, or
  • transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

  • Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
  • Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
  • Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
  • Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.

Tell your friends and colleagues about us. Thanks!
Share this
Information Security Best Practices

What is more important – patient safety or hospital IT?

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

A threat analysis was performed on a medical device used in intensive care units.  The threat analysis used the PTA (Practical threat analysis) methodology.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).

Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this
informed-consent-consideration

Why HIPAA Policies and Procedures are not copy and paste

Compliance from Dr. Google is a very bad idea.

Searching for HIPAA Security Rule compliance yields about 1.8Million hits on Google. Some of  the information is outdated and does not relate to the Final Rule and a good deal of other information is sponsored by service providers and technology companies selling silver bullets for HIPAA compliance.

The online dialog on HIPAA Security Rule compliance is dominated by discussions by requirements for health providers.   There is very little information online for the downstream medtech and medical device vendors who are increasingly using the cloud to store data and process transactions for their covered entity customers

If you are a small medtech or medical device company, and you copy from a big healthcare provider you will be overpaying and over-implementing SOP’s which may not be relevant to your business situation.

The risk analysis for a SaaS provider or medical device that stores PHI in the cloud is not even remotely similar to the risk analysis for a hospital.

If you copy and paste a risk analysis – you won’t understand what you’re doing and why you’re doing it and since HIPAA privacy infractions carry both a criminal civil penalty, you don’t want to even attempt to comply via Google.

For example – if you are a mobile medical device vendor – you will need to take into account technology and privacy considerations such as mobile app software security, application activity monitoring, mobile and cloud data encryption and key management none of which may be relevant for a traditional IT hospital-run electronic health records system.

What policies and procedures do I need for HIPAA compliance?

We provide clients with  a bespoke package of SOP’s which are required by HIPAA – Acceptable use, Incident response, Security and risk management process, Disaster recovery plan, and Security Officer Job description (which is required by the Final Rule).     This is in addition to the Risk Analysis / Security Assessment report (§ 164.308(a)(1)(ii)(A) ).

6 reasons why  HIPAA security policies and procedures are not copy and paste:

  1. It depends on the business situation and technology model. A biotechnology company doing drug development will not have the same threat surface as a mobile health company.
  2. Your security is worse than you think. When was the last time you looked? Or had an external audit of your encryption policies?
  3. It also depends on timing – if the life science company is doing clinical research, then informed consent may release the sponsor from HIPAA privacy rule compliance. But in clinical research, physician-investigators often stand in dual roles to the subject: as a treating physician (who has to comply with the HIPAA Privacy Rule) and as a researcher (who has to comply with both GCP and 21 CFR Parts 50 and 56 regarding informed consent with adults and children).  In my experience with medical device companies, they often do clinical trials in parallel to commercial betas and work closely with physician-investigators. This means that your HIPAA Security Rule compliance posture needs to be nailed down in order to eliminate holes of privacy leakage.
  4. Life science companies have quality management systems as part of their FDA submissions – the HIPAA Security Rule policies and procedures need to become part of your quality system.We work with you to make sure that your regulatory/QA/QC leads understand what it means to implement them and help them integrate into their own internal formats, policies and training programs.
  5. Covered entities may also have impose specific  requirements in their BAA on the life science vendor;  we then need to customize the policies and procedures to comply with the their internal guidelines.     Sometimes these are quite strange like  the story of the West Coast hospital that deliberately weakened the WiFi signal of their routers in the thought that it was a security countermeasure for hacking their wireless access points.
  6. There are also situations of intersection with other Privacy regulation such as CA 1280.15 for Data breach – California is sticky on this and then if  you do business with U of C – there are will be additional things to cover

Feel free to contact us  for a free quote – we’re always looking for interesting projects.

 

Tell your friends and colleagues about us. Thanks!
Share this
Bridging the security IT gap with BI

Encryption and medical device cyber security

I have written pieces here, here, here and here on why encryption should be a required security countermeasure for network medical devices – but curiously, the HIPAA Security rule – Appendix A does not specifically require encryption.

The final FDA guidance on cyber security for medical devices takes a similar position that we’ve adopted over the years – namely analyzing threats (“Hazards”) and implementing a prioritized security countermeasure plan.

In our security and privacy compliance practice for biomed in Israel – we always take a position that the first step in determining the best and most cost-effective security countermeasures for your medical device is to develop a threat model and perform a threat analysis.  Encryption may or may not be the first security countermeasure you must implement in your mobile medical device (think about fixing interface bugs first…) but it will probably be in your top 5

Regardless of why the authors of the HIPAA security rule did not require encryption – it is instructive to take a look at the history of encryption and how we arrived at where we are today – where encryption is widely considered to the silver bullet of security.

History of EncryptionLearn about key cryptology events throughout
the ages with the Egress History of Encryption infographic. Egress
Software Technologies are providers of email encryption software and file encryption & large file transfers.

Tell your friends and colleagues about us. Thanks!
Share this
Anat kamm

Procedures are not a substitute for ethical behavior

Are procedures  a substitute for responsible and ethical behavior?

The  behavior of former secretary  of  State (and Presidential race loser) Hilary Clinton is an important example of how feeling entitled is not the exclusive domain of under 20-somethings. When we do a threat analysis of medical devices, we try to look beyond the technical security countermeasures and dive into the human factors of employees and managers of the organization.

Leadership from the front trumps security technology.

President Obama’s notion of leading from behind is problematic in the data security and governance space – leadership is about leading from the front.

President Obama’s weak position on enforcing data security and privacy in his administration (Snowden, Clinton and NSA) set a poor example that will take years to undo and probably cost Hilary Clinton the election.

In the business environment,  management leadership from the front on data security and privacy is a more effective (as in cheaper and stronger) countermeasure than technology when it comes to mitigating trusted insider threats.

In the family environment, we traditionally see parents as responsible for taking a leadership position on issues of ethics and responsible behavior.

Has mobile changed this?

Sprint  announced new services that  will allow parents to set phone use limits by time of day or week, see daily calls, text messaging and application activity of their children.  Sprint Mobile Controls powered by Safely, a division of Location Labs,  allows parents to see rich graphical representations of how their family calls, texts and use applications and to lock phones remotely at specific times.

For example:

  • Seeing who your son or daughter has been calling or texting recently – and how often.
  • Establishing an allowed list of phone numbers from which your child can receive a call or text.
  • Seeing a list of your child’s contacts with an associated picture ranked by overall texting and calling activity.
  • Viewing what apps your child is downloading to their phone.
  • Choosing up to three anytime apps that your child can use when their device is locked.
  • Allowing your child to override phone restrictions in case of an emergency.
  • Setting alert notifications for new contacts, or School Hours and Late Night time periods.
  • Setting Watchlist contacts: Receive alert notifications when your child communicates with a Watchlist contact.

This seems like a similar play to product and marketing initiatives by credit card companies to control usage of credit card by children using prepaid cards like the Visa Buxx – except in the case of Visa the marketing message is education in addition to parental control:  Visa Buxx benefits for parents and teens include:

  • Powerful tool to encourage financial responsibility
  • Convenient and flexible way to pay
  • Safer than cash
  • Parental control and peace of mind
  • Wide acceptance—everywhere Visa debit cards are welcome

Visa Buxx was introduced almost 10 years ago. I don’t have any data on how much business the product generates for card issuers but fast forward to December 2011, the message of responsibility has given way to parental control in the mobile market:

In the case of mobile phones, I can see the advantage of a home privacy and security product. From Sprint’s perspective; controlling teens is a big untapped market. Trefis. (the online site that analyzes stock behavior by product lines) has aptly called it “Sprint Targets Burgeoning Teen Market with Parents Playing Big Brother

The teen market, consisting of those in the 12 to 17 year age group, is plugged into cellular devices and plans to a much greater extent than you might imagine. According to a Pew Internet Research study, more than 75% of this group owns a wireless phone. This isn’t news to Sprint Nextel (NYSE: S) or mobile phone competitors such as Nokia (NYSE:NOK), AT&T (NYSE:T) and Verizon (NYSE:VZ).

I do not believe that technology is a replacement for education.

It will be interesting to track how well Sprint does with their teen privacy and security product and if parents buy the marketing concept of privacy controls as a proxy for responsible behavior.

Tell your friends and colleagues about us. Thanks!
Share this
Federal Healthcare Chart

The chasm between FDA regulatory and cyber security

 

When a Risk Analysis is not a Risk analysis

Superficially at least, there is not a lot of difference between a threat analysis that is part of a software/hardware security assessment and a risk analysis (or hazard analysis) that is performed by a medical device company as part of their submission to the FDA.    In the past 2 years, FDA added  guidance for cybersecurity for medical devices and the format and language of the guidance is fairly similar.

The problem is that hazard analysis talks about patient safety and relates to the device itself as a potential attacker whereas software  security talks about confidentiality of patient data, integrity of the code and its data and credentials and system availability and relates to the device as a black box.

So in fact – medical device risk analysis and cyber security assessments are 2 totally different animals.

Some of my best friends work in medical device regulatory affairs. I admire what they do and I like (almost) all of them on a personal basis.

But – over the past year, I have been developing a feeling of deep angst that there an impossible-to-cross chasm of misunderstanding and philosophy that exists between medical device regulatory people and medical device security analysts like me.

But I can no longer deny that even at their best – regulatory affairs folks will never get security.

Why do I say this?   First of all – the empirical data tells me this.  I  interface with several dozen regulatory professionals at our medical device security clients in Israel and the best of them grasp at understanding security.  The worst cases hang on to their document version controls for dear life and claim earnestly even as they are hacked that they cannot modify their device description because their QA process needs several weeks to approve a 3 line bug fix. (This is a true story).

We intend to implement encryption of EPHI in our database running on a cloud server since encryption uses check sums and check sums ensure integrity of the data and help protect patient safety.
True quote from a device description of a mobile medical device that stores data in the cloud…the names have been concealed to protect the innocent.  I did not make this up.

The chasm between FDA regulatory and cyber security

The second reason I believe that there is an impossible-to-cross chasm between medical FDA device regulatory people and medical device security is much more fundamental.

Systems like mobile medical devices live in the adversarial environment of the Internet and mobile devices. Unlike traditional engineering domains like bridge-building that are well understood and deal with winds that obey rules of physics and always blow sideways; security threats do not play by set rules. Imagine a wind that blows up and down and then digs underground to attack bridge pylons from 50m below earth and you begin to understand what we mean when we say “adversarial environment”.

General classes of attacks include elevation of privilege, remote code execution, denial of service and exploits of vulnerable application interfaces and network ports. For example:

  • Attacker that steals personal data from the cloud by exploiting operating system bugs that allow elevation of privilege.  Zero-days that were unknown when your QA people did V&V.
  • Attacker that exploits vulnerabilities in directory services that could allow denial of service. What ?  We’re using directory services???
  • Attacker that tempts users to download malicious mobile code that exploit mobile APIs in order to steal personal data. What?  This is just an app to measure blood sugar – why would a patient click on an add that injects malicious code into our code while he was taking a picture of a strip to measure blood sugar??

We talk about an attacker in an abstract sense, but we don’t know what resources she has, when she will attack or what goals she has. Technology changes rapidly; a system released 2 years ago may have bugs that she will exploit today. Our only recourse is to be paranoid and think like an attacker.

Thinking like attackers not like regulators

By being extremely paranoid and thinking like attackers, medical device security requires us to systematically consider threat models of attacks, attack vectors, assets at risk, their vulnerabilities and appropriate security countermeasures for prevention, detection and response.

While this approach is not a “silver bullet” it lends structure to our paranoia and helps us do our job even as the rules change.

And this where the chasm begins.   The rules change.   There is no QA process. There are no rules.   We are not using IEEE software engineering standards from 40 years ago.  They are useless for us.

Dorothy – we are not in Kansas anymore. And we are definitely not in Washington DC in a regulatory consulting firm of high-priced lawyers.

 

 

Tell your friends and colleagues about us. Thanks!
Share this

PCI DSS is a standard for the card associations not for your business

 

I recently saw a post from a blog on a corporate web site from a company called Cloud compliance, entitled “Compliance is the New Security Standard“.

Cloud Compliance provides a SaaS-based identity and Access Assessment (IdAA) solution that helps identify and remediate access control and entitlement policy violations. We combine the economies of cloud computing with fundamental performance management principles to provide easy, low cost analysis of access rights to prevent audit findings (sic) and ensure compliance with regulations such as SOX, GLBA, PCI DSS, HIPAA and NERC.

The basic thesis of the blog post was that since companies have to spend money on compliance anyhow, they might as well spend the money once and rename the effort “security”.   This is an interesting notion – although perhaps “placebo security” might be a cheaper approach.

Compliance is not equivalent to security  for several fundamental reasons.  Let’s examine this curious notion, using  PCI DSS 1.2 as a generic example of a regulatory compliance standard that is used to protect payment card numbers:

A. Filling out a form or having an auditor check off a list is not logically equivalent to installing and validating security countermeasures. A threat modeling exercise is stronger than filling out a form or auditing controls – it’s significant that threat modeling is not even mentioned by PCI DSS, despite the ROI in think time.

B. Although PCI DSS 1.2 is better than previous versions – it still lags the curve of typical data security threats – which means that even if a business implements all the controls – they are probably still vulnerable.

C. PCI DSS was designed by the card associations – there is no way that any blanket standard will fit the needs of a particular business – anymore than a size 38 regular suit will fit a 5′ 7″ man who weighs 120 kg and wrestles professionally.

D. PCI DSS talks about controls with absolutely no  context of value at risk. A retailer selling diamond rings on-line, may self-comply as a Level 4 merchant but in fact have more value at risk than then the payment processor service provider he uses. (See my previous post on Small merchants at risk from fraudulent transactions )

E. PCI DSS strives to ensure continued compliance to their (albeit flawed) standard with quarterly (for Level 1) and yearly (for everyone else) audits.   The only problem with this is that a lot of things can happen in 3 months (and certainly in a year).   The automated scanning that many Level 2-4 merchants do is essentially worthless but more importantly – the threat scenarios shift quickly these days – especially when you take into account employees and contractors who as people are by definition, unpredictable.

F. Finally – PCI DSS is a standard for whom? It’s a standard to help the card associations protect their supply chain.   It is not a policy used by the management of a company in order to improve customer service and grow sales volume.

F. PCI DSS 1.2 mandates security controls for untrusted networks and external attacks.   The phrases “trusted insider” or “business partner” are not mentioned once in the standard. This is absurd, since a significant percentage of the customer data breaches in the past few years involved trusted insiders and business partners. A card processor can be 100 percent compliant but because they have a Mafia sleeper working in IT – they could be regularly leaking credit card numbers. This is not a theoretical threat.

To summarize:

  • PCI DSS is a standard for the card associations not for your business nor for your customers.
  • As a security standard it is better than none at all but leaves much to be desired because it is not oriented towards the business and consumer protection
Tell your friends and colleagues about us. Thanks!
Share this
safeguard your head office small business

How to secure your data when firing employees

 

What kind of risk are you creating when you fire the IT security officer?

When a company decides to fire a big piece of it’s work force – it’s to reduce costs in anticipation of reduced revenues. Risk management and IT governance runs a distant second and third when it’s a question of survival. The IT department is often in the line of fire, since they’re a service organization. The IT security staff may be the first to get cut since  companies view information security as a luxury, not as a must to run the business.

There is nothing in the information security policy of any organization that I have seen that talks about how to manage risk when 300 employees are being fired in a short period of time in a business unit.

What is your risk appetite?

A key part of formulating and establishing information security   policies for your organization is in deciding how much risk is   acceptable and how to minimize unacceptable risk.

This process initially involves undertaking a formal risk assessment which is a  critical part of any ISMS.  However – it’s a mistake to assume that risk assessment is a static process when the business is a dynamic process.  Risk assessment must be dynamic and continuous, moving at the front line of the business not as an after though or not at all.

The ISO 27000 standards provide some guidance on how this  risk assessment process is to be undertaken.  This guidance is   summarized and annotated below:

  • Use systematic approach to estimate magnitude of risks (risk  analysis)
  • Compare estimated risks against risk criteria to measure the  significance of the risk (risk evaluation)
  • Define the scope of the risk assessment process to improve  effectiveness (risk assessment)
  • Undertake risk assessments periodically to address changes in  assets, risk profiles, threats, safeguards, vulnerabilities and risk  appetite (risk management)
  • Risk measurement should be undertaken in a methodical manner to  produce verifiable results (risk measurement)

The stumbling block to doing continuous risk assessment is both world view (“hire a consultant once every 2 years to check us out”) and technical (“the cost of said consultant”).  We have a great  free ISO 27001 risk assessment software that can automate the process, save you money and help you respond fast to changes in the business. The software is based on the popular PTA (practical threat analysis) Professional risk assessment tool.

Tell your friends and colleagues about us. Thanks!
Share this
Ethics and data protection

Why the Clinton data leaks matter

In the middle of a US Presidential election that will certainly become more contrast-focused (as politically correct Americans like to call mud-slinging), the Clinton data leaks are interesting and also worth investigation for their longer-term impact on the US economy,

Shaky ethics versus data protection

A friend who is a political science professor told me that Hilary was no different than other US politicians who walk the wrong side of the line of data protection.

But the Hilary Clinton private mail server, her flagrant disregard for protecting sensitive government communications and her dubious personal ethics on US State Department data security policies is much much more than a peculiarly American political issue that is news today and gone tomorrow.

Back in October 2015, the EU High Court struck down a the Safe Harbor agreement – a trans-Atlantic pact used by thousands of companies to transfer Europeans’ personal information to the U.S., throwing into jeopardy data traffic that underpins the world’s largest trading relationship.

The Safe Harbor executive decision allows companies to self certify to provide “adequate protection” for the data of European users to comply with the European data protection directive, and with fundamental European rights such as the right to privacy (under Article 8 of the European Convention for the Protection of Human Rights).

The Americans are just slow or maybe they don’t care about privacy

The Commission issued 13 recommendations for improving Safe Harbor in November 2013 (that is 2 years before the EUJ ruling ) but negotiations to rework the framework are still ongoing.

The ECJ’s judgement is the culmination of a 2013 legal challenge by European privacy campaigner Max Schrems who filed complaints against several U.S. Internet giants — including Facebook — in the Irish courts for alleged collaboration with the NSA’s Prism program. The Irish courts dismissed the complaint.

Why it matters to the rest of the world

A large number widely quoted  (4,700) of US companies rely on Safe Harbor to operate businesses in the region. It also affects those companies that outsource data processing of E.U. users’ data to the U.S.

However – many more than 4700 US companies are affected by Safe Harbor dismissal.    Any company with a US corporate presence will also be impacted.    We saw this recently with an Israeli biotech company with offices in Boston who was requested by a Danish hospital to provide alternate assurances for data protection.   This is a curious case where it is actually better to be Israeli rather than American.

The EU has recognized that the State of Israel provides an adequate level of protection for personal data as referred to in Directive 95/46/EC with regard to automated international transfers of personal data from the European Union to the State of Israel or, where those transfers are not automated, they are subject to further automated processing in the State of Israel.  See this EU ruling on Israeli data protection

You can see the full list of countries (not the US) that provide adequate data protection here.

Long term impact to US economy?

With Snowden, Prism, the contrasted  US Presidential elections, the Hilary Clinton data leaks and the attempts by the FBI to establish a dangerous anti-privacy precedent under the guise that they cannot hack an Apple iPhone – I would not expect resolution of Safe Harbor anytime soon.

The long term impact will be innovative technology / cloud / SaaS companies like our Biotech customer with Boston offices, taking their business out of the US to safer harbor places like Tel Aviv.

Which has better weather than Boston anyhow.

Tell your friends and colleagues about us. Thanks!
Share this
cyber attacks

Why audit and risk management do not mitigate risk – part II

In my previous post Risk does not walk alone – I noted both the importance and often ignored lack of relevance of internal audit and corporate risk management to the business of cyber security.

Audit and risk management are central to the financial services industry

Just because audit and risk management are central to the financial services industry does not make them cyber security countermeasures. Imagine not having a firewall but having an extensive internal audit and risk management activity – the organization and all of it’s paper, policy and procedures would be pillaged in minutes by attackers.

Risk management and audit are “meta activities”

In the financial industry you have risk controls which are the elements audited by internal audit and managed by risk management teams. The risk controls are the defenses not the bureaucracy created by highly regulated industries. So – you can have a risk control of accepting (deciding not to have end point security and accepting the risk of data loss from employee workstations), or mitigating (installing end point DLP agents) or preventing (taking away USB ports and denying Internet access) etc…This is analogous to a bank accepting risk (giving small loans to young families), mitigating (requiring young families to supply 80% collateral), and preventing (deciding not to give loans to young families).

The important part is to understand that risk management and audit are “meta activities” and not defenses in their own right.

Why risk management often fails in cyber security operations

We note that attempts to apply quantitative risk management to cyber generally do not work because the risk management professionals do not understand cyber threats and equate people and process with mitigation.

Conversely – cyber-security/IT professionals do not have the tools to estimate asset value.  Without taking into account asset value, it is impossible to prioritize controls as every car owner knows: you don’t insure a 10 year old Fiat 500 like you insure a late model Lexus RC F.

Unfortunately for the lawyers and regulatory technocrats – while they are performing cross-functional exercises in business alignment of people and processes – the bad guys are stealing 50 Million credit cards from their database servers having hacked their way through the air conditioning systems.

Why cyber, regulatory and governance need to be integrated

Risk management prioritizes application of controls/cyber countermeasures according to control cost, asset value and mitigation effectiveness and internal audit ensures compliance with the company’s cyber, regulatory  and corporate governance policies.

Because these 3 areas (cyber, regulatory and governance) are increasingly entangled and integrated (you can’t comply with HIPAA without dealing with all 3) – it becomes supremely important to integrate the 3 areas because A) it’s expensive no to and B) it creates considerable exposure because it creates “cracks” in compliance.    Witness Target.

At a major Scandinavian telco – we counted over 25 separate functions for security, compliance and governance a few years ago  – and it was clear that this number needed to converge to 2 – risk and cyber and an independent audit unit. Whether or not they succeeded is another story.

Tell your friends and colleagues about us. Thanks!
Share this