Category Archives: Risk mitigation

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
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
hipaa cloud security

How do you know that your personal health data is secure in the cloud?

Modern system architecture for medical devices is a triangle of Medical device, Mobile app and Cloud services (storing, processing and visualizing health data collected from the device).  This creates the need for verifying a chain of trust: patient, medical device, mobile app software, distributed interfaces, cloud service software, cloud service provider.

No get out of jail free card if your cloud provider is HIPAA compliant.

We specialize in medical device security and as I’ve written here and here and here – and there is no silver marketing bullet.

Medical device vendors must implement robust software security in their device, app and cloud service layers and implement regulatory compliance in people and technical operations. If you are a medical device vendor, you cannot rely on regulatory compliance alone, nor can you rely on your cloud provider being HIPAA compliant.  I’ve written here and here how medical devices can be pivot points for attacking other systems including your customers’ and end users devices.

Regulatory compliance is not security

There are two notable regulatory standards relating to medical devices and cloud services – the HIPAA Security Rule and the FDA Guidance for Management of cybersecurity in medical devices. This is in addition to European Data Protection requirements and local data security requirements  that a particular country such as France, Germany or New Zealand may enforce for protecting health data in the cloud.

The American security and compliance model is unique (and it is typically American in its flavor) – it is based on market forces – not government coercion.

Complying with FDA Guidance is a requirement for marketing your medical device in the US.

Complying with the HIPAA Security Rule is a requirement for customers and covered entity business associates to buy your medical device.   You can have an FDA 510(K) for your medical device and still be subject to criminal charges if your cloud services are breached.   HHS has announced  in the Breach Notification Rule and here that they will investigate all breaches of 500 records and more. In addition, FDA may enforce a device recall.

But – compliance is not the same as actual enforcement of secure systems

Verifying the chain of trust

Medical device vendors that use cloud services will generally sign upstream and downstream business associate agreements (BAA) but hold on:

There is an elephant in the room:  How do you know that the cloud services are secure?  If you have a data breach, you will have to activate your cyber-security insurance policy not your cloud providers sales team.

Transparency of the cloud provider security operations varies widely with some being fairly non-transparent ()and others being fairly transparent (Rackspace Cloud are excellent in their levels of openness before and after the sale) in sharing data and incidents with customers.

When a cloud service provider exposes details of its own internal policy and technology, it’s customers (and your medical device users) will tend to trust the provider’s security claims. I would also require transparency by the cloud service providers regarding security management, privacy and security incident response.

One interesting and potentially extremely valuable initiative is the Cloud Trust Protocol.

The Cloud Trust Protocol (CTP) enables cloud service customers to request and receive data regarding the security of the services they use in the cloud, promoting transparency and trust.

The source code implements a CTP server that acts as a gateway between cloud customers and cloud providers:

  • A cloud provider can push security measurements to the CTP server.
  • A cloud customer can query the CTP server with the CTP API to access these measurements.

The source code is available here on Github.

 

 

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

Why Google is a bad idea for security and compliance

Dear consultant,

I worry because so many of the best practices documents I read say that we need to store data in the cloud in Canada if we do business in Canada. See page 19 here – Health privacy in Canada

Sincerely – consumer healthcare product manager

Dear consumer healthcare product manager –

First of all. Don’t worry be happy! Thanks for sharing.

Everyone uses Google to ask questions.  That includes security and compliance specialists in Israel for biomed like me (Danny Lieberman) and my company (Software Associates).

The problems start when clients start consulting with Google for their data security and privacy compliance affairs.   Unlike healthcare problems, where there are very large numbers of people asking and answering questions and wisdom of the crowds kicks in – data security and privacy compliance is a niche market and it’s very political.

The bottom line is that you do not have host locally in Canada – until they change the law.

There is no specific legal requirement in Canadian law for country-hosting (as in France).

Unfortunately – as elsewhere in the world – there is a certain amount misinformed, and/or politically-motivated media discussion following the Snowden affair.

People that write these documents like to point at the US Patriot Act as a reason for country hosting – by not bothering to note what the Patriot Act really is – a US law that is intended to Provide Appropriate Tools Required to Intercept and Obstruct Terrorism and intercept lone wolf terrorists.

The suggestion that the NSA will intercept depersonalized consumer health records that you collect in your application  as part of the war on individual terrorists borders on the absurd.

Suppose you have a user who is obese and/or has Type II diabetes and/or is pregnant and/or loves to dance Zumba.  Is that information part of the NSA threat model for lone wolf terrorists?

I don’t think so.

The document in question  makes an  absurd suggestion on Page 19 that individual doctor offices are more secure than in a Tier 1 Cloud service provider.

The data loss risk in a doctor office is several orders of magnitude higher than in Microsoft, Amazon or Rackspace cloud hosting facilities.

Since the document is misleading from a security and compliance perspective (misleading regarding the Patriot Act and incorrect regarding data loss risk) – we see that we cannot rely on it as a source of so-called “security best practices”.

In general – it is not best practice to use Google for security and compliance best practice.

Yours,

Danny Lieberman-Security and compliance specialists for biomed companies

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

Kick start your European privacy compliance

The CNIL’s Sanctions Committee issues a 150 000 € monetary penalty to GOOGLE Inc.

On 3 January 2014, the CNIL’s Sanctions Committee issued a 150 000 € monetary penalty to GOOGLE Inc. upon considering that the privacy policy implemented since 1 March 2012 does not comply with the French Data Protection Act. It ordered the company to publish a communiqué on this decision on its homepage Google.fr, within eight days as of its notification.

Does your web site / web service / web application have a privacy policy?

Was that privacy policy written by lawyers who may or may not understand your business and may or may not understand that European states like France have their own regulation of privacy?

You may be facing a stiff penalty for having a non-compliant privacy policy.

The CNIL penalty on Google is a wake-up call.

Thousands of  service providers just like you are sitting on the fence and wondering how to comply with European and French privacy regulation as fast and as effective as possible.

Where do you start?

We’re here to help you get going fast with some common Q&A

Q. Is my existing privacy policy sufficient?

A. Maybe. Maybe not.    A 2 hour review with  with us will give you a clear picture of what you need to do. After the review we will help you rewrite your your privacy policy and terms of service in order to minimize your exposure. For starters, here are 4 points you need to cover:

  1. Does your site sufficiently inform its users of the conditions in which their personal data are processed?
  2. Does your site obtain user consent prior to the storage of cookies?
  3. Does your site define retention periods applicable to the data which it processes?
  4. Does your site  permit itself to combine all the data it collects about its users?

Q. What special systems or security products are required?

A. None. Security defenses are a mistake.  See the next question and answer.

Q. How many hours should I budget for Data Protection compliance? How should I protect my data?

A.  We have an 8 week plan to take you from zero to full Data Protection compliance – budget 6 hours / week and you will get there. You also need to identify and mitigate vulnerabilities in your Web site – our Practical Threat Analysis process will pinpoint what you need to do from a perspective of policies and procedures, cloud servers and application security.

Q. What do I do when I complete the 8 week plan for Data Protection compliance?

A. Well, you’ll be sitting on a much more robust system of technical, administrative, policy and procedural controls so go out and have some fun – you deserve it!

If you provide digital services in countries like France and the UK who have local database registration requirements – we will help you comply with local CNIL and UK Data Commissioner requirements.

See CNIL Sanctions on Google for the full story.

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

Software in Medical Devices – Update

We have previously written about various aspects of the software development process, especially, the verification and validation activities in implanted and invasive medical devices.

Here is  an update on what is happening in the regulatory arena and how the regulatory groups are checking up on what we are doing.

Software Recalls 2012

The estimate for software recalls by the FDA for 2012 is 173. The software recalls for 2011 were 177 and for 2010 were 76. So far there are quite a few software recalls in 2013.

There are a number of new guidances and standards released and soon to be released – it’s worth getting up to speed if you are developing software for medical devices and concerned about reliability and software security:

  1. 21 CFR 880.6310, Medical Device Data Systems, FDA – released. This standard relates to hardware or software products that transfer, store,convert formats, and display medical device data. This application can be defined as a medical device which is a Class I device instead of the classification of your system. It has been used by a number of companies to define gateways between systems.
  2. ISO 82304-1, Healthcare Software Systems – Part 1: General Requirements For Product Safety – to be released maybe later this year. There is a draft copy out. This relates to medical devices that are only software. 
  3. MEDDEV 2.1/16, January 2012 – Guidelines on the qualification and classification of standalone software used in healthcare within the Regulatory framework of medical devices 4) ISO/IEC TIR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software – refers to the risk analysis on the software. This is an interesting aspect as we tend to analyze the risks on a system level.  If you have any questions please contact us. 
  4. ISO/IEC TR 80002-02, Medical device software – Part 2: Validation of software for regulated processes – to be released maybe later this year. This refers to software used in the all other aspects in the organization. 
  5. IEC 80001-1:2010, Application of Risk Management for IT Network incorporating Medical Devices – This is the risk management doctrine for hospitals, etc. employing medical devices on the network. If you supply your system to a hospital, you may be requested to let the hospital know if you are 8001 compliant. Once we know more on this, we’ll update you. 
  6. AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software – This is a technical report from the AAMI on the use of Agile in the software development.
  7. AAMI/ANSI SW87:2012, Application of Quality Management System concepts to Medical Device Data Systems (MDDS) – provides guidance for Application of Quality Management System concepts to Medical Device Data Systems (MDDS) 
  8.  AAMI TIR on Guidance on Health Software Safety and Assurance – future release
  9.  AAMI TIR on Classification of defects contributing to unacceptable risk in health software – future release

Click here to download the full article on FDA standards and guidance and software in medical devices  Software Update 020613

Courtesy of my colleague Mike Zeevi

Tell your friends and colleagues about us. Thanks!
Share this
Cyber warfare pentagon cyberwar

Is cyber security and mobile device management important in the healthcare industry?

Is cyber security and mobile device management important in the healthcare industry?

Healthcare and technology go hand in glove more than almost any other sector in today’s business world. This statement is true today and will remain so into the future. Patient records form just one element of the vast mountain of data that is stored and processed everyday by all healthcare providers be they a local GP’s surgery or a teaching hospital. These records are some of the most sensitive data there is, protecting this data from accidental or malicious access is becoming increasingly difficult.

Just think of the many and varied mobile devices there are today designed to either plug-in, wirelessly connect or Bluetooth connect to your network or computer system. Can we police and manage these connections? After all when access is required, by bona fide healthcare professionals, this ease of connection and access is a very desirable requirement. But the security of this access is paramount not least because there is a legally enforceable duty of care to protect this sensitive data.

In an ideal world the holder of any sensitive data would be able to control and audit the sharing of that data throughout its lifetime. That touches on another valid concern, that of when is data irrecoverably deleted, we should look at this issue in another blog. If we accept the premise that no amount of added security can be totally full proof what we need is away of mitigating the risk. The use of encryption technology seems to be the answer. If data is encrypted when at rest or during transportation between two points it is less lightly to be compromised.

At this point we should consider the implications for the individual data user. Any security system that alters the users normal working practices will be resisted and subverted wherever possible. Human nature is not normally predisposed to thinking security. The average user in the course of their normal day’s work will access many different data sources, may transfer data between differing media devices and share that data with other users, all quite legitimately. If at every stage of this data interaction they are challenged or required to do something extra that takes time, thought or additional actions the system will not be adopted or accepted.

The latest generation of security systems has taken note of this human response to security. It has acknowledged the fact that we as users are quite willing to pay lip service to the need for robust security providing it doesn’t affect our daily lives in an obtrusive way. In just the same way as you would expect your passage to be controlled within a secure building so your access to data will be, according to your personal privileges, the key being your authentication at the front door or access point. Once inside your set of privileges dictates your access to and actions that can be performed to the data. All of this will be audited for later analysis. These personal privileges should, in a well designed system, be dynamic. By this I mean that your privileges can be modified in real time, what you can do today you might not be able to do tomorrow. Keeping data available on a need to have access basis help limit the possibility of compromise.

And what of that data that you shared? Where is it now and is it still being controlled securely? Just because it has left your system has it suddenly become less sensitive? Unlikely! The system should be capable of extending it’s security to that data that has been shared beyond the network. Email or thumb drives are just two easy routes for the leaking of sensitive data. Be sure the system you consider has taken this into account.

I hope this very brief blog has shed some light on the various issues that confront those responsible for the security of the data they hold. You can find out more about cyber security here

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

Debugging security

There is an interesting analogy between between debugging software and debugging the security of your systems.

As Brian W. Kernighan and Rob Pike wrote in “The Practice of Programming

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

In programming, it is faster to examine the contents of a couple of variables than to single-step through entire sections of code.

Collecting security logs is key to information security management not only for understanding what and why an event happened but also in order  to  prove regulatory compliance with regulations such as the HIPAA security rule. The business requirements are that   security logs  should be both relevant and effective.

  1. Relevant content of audit controls:  For example, providing a  detailed trace of an application whenever it elevates privilege in order to execute a system level function.
  2. Effective audit reduction and report generation:  Given the large amount of data that must be analyzed in security  logs, its crucial that critical events are separated from normal traffic and that concise reports can be produced in real-time to help understand  what happened, why it happened and how it was mediated and how to mitigate similar risks in the future.

In security log analysis, it is faster and definitely more effective for a security analyst to examine the contents of a few real time events than to process gigabytes or terabytes of security logs (the equivalent of stepping through or placing watch points in sections of of a sub-modules with  hundreds or thousands of lines of code.

When you have to analyze security logs, it is easy to get lost in details of complicated data and flows of events and find yourself drifting off into all kinds of directions even as the bells go on in the back of your mind that you are chasing ghosts in a futile and time-consuming exercise of investigation and security event debugging.

In order to understand this better, consider another analogy, this time from the world of search engines.

Precision and recall are key to effective security log analysis and effective software debugging.

In pattern recognition and information retrievalprecision is the fraction of retrieved instances that are relevant, while recall is the fraction of relevant instances that are retrieved. Both precision and recall are therefore based on an understanding and measure of relevance. When a program for recognizing the dogs in a scene correctly identifies four of the nine dogs but mistakes three cats for dogs, its precision is 4/7 while its recall is 4/9. When a search engine returns 30 pages only 20 of which were relevant while failing to return 40 additional relevant pages, its precision is 20/30 = 2/3 while its recall is 20/60 = 1/3. See Precision and recall in the Wikipedia.

In other words – it doesn’t really matter if you have to analyze a program with 100,000 lines of code or a log file with a terabyte of data – if you have good precision and good recall.

The problem is however, that the more data you have, the more difficult it is to achieve high precision and recall and that is why real-time events (or  debugging statements) are more effective in day-to-day security operations.

 

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

Encryption, a buzzword, not a silver bullet

Encryption,  buzzword, not a silver bullet for protecting data on your servers.

In order to determine how encryption fits into server data protection, consider 4 encryption components on the server side: passwords, tables, partitions and  inter-tier socket communications.

In these 4 components of a application / database server encryption policy, note that some countermeasures are required (for example one-way hashes of passwords, while other such as encrypting specify table columns may or may not be relevant to a particular application).

1. Encrypted password storage

You must encrypt passwords. It’s surprising to me how many Web sites don’t bother encrypting user passwords – See cases Universal Music Portugal where e-mail addresses and clear-text passwords are dumped on Internet.

What is more surprising is the confusion between encryption and hashing.

Don’t use AES for encrypting passwords in your MySQL or Oracle or MS SQL database.  You’ll end up storing the AES key somewhere in the code and an attacker or malicious insider can read the key by opening up one of your application DLLs in Notepad++ and read that key in a jiffy and breach your entire MySQL database with a single SELECT statement.

Database user passwords should be stored as MD5 hashes, so that a user  (such as a DBA) who has been granted SELECT access to the table (typically called ‘users’)  cannot determine the actual password. Make sure that different instances have different salts and include some additional information in the hash.

If you use MD5 encryption for client authentication, make sure that  the client hashes the password with MD5 before sending the data on the network.

2. Encrypt specific database table columns

The PostgreSQL 9.1 pgcrypto module allows certain fields to be stored encrypted. This is especially useful if some of the data is sensitive for example in the case of ePHI where the Web application needs to comply with the CFR 45 Appendix A Security rule. The client software provides the decryption key and the data is decrypted on the server and then sent to the client.  In most cases the client (a database driver in an MVC application such as Ruby on Rails or CakePHP or ASP.NET MVC is also a server side resource and often lives on the same physical server as the database server. This is not a bad thing.

3. Encrypt entire data partitions

Encrypting entire data partitions has its place.

On Linux, encryption can be layered on top of a file system using a “loopback device”. This allows an entire file system partition to be encrypted on disk, and decrypted by the operating system. Many operating systems support this functionality, including Windows.

Encrypting entire partitions is a security countermeasure for physical attacks, where the entire computer is stolen. Research we did in 2007 indicated that almost 50% of large volume data breaches employed a physical attack vector (stealing a notebook at a hotel checkin desk, hijacking a truck transporting backup tapes to Iron Mountain and smash and grab jobs where thieves know the rent-a-cop walkaround schedule and break in and steal desktop computers.

On the other hand, once the volume is mounted,  the data is visible.

4. Encrypt socket communications between server tiers

SSL has it’s place, although SSL is not a silver bullet countermeasure for Microsoft Windows vulnerabilities and mobile medical devices vulnerabilities as I wrote herehere and here.

SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. In database client-server connections,  relational database systems such as PostgreSQL allow administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.

 

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

Ten steps to protecting your organization’s data

Here are 10 steps  to protecting your organization’s privacy data and intellectual property.

As a preface, begin with the understanding that you already have all the resources you need.

Discussions with colleagues in a large forensics accounting firm that specialize in anti-fraud investigations, money laundering and anti-terror funding (ATF), confirm what I’ve suspected for a long time. Armies of junior analysts working for the large accounting firms who have never seen or experienced a fraudulent event and are unfamiliar with the your business operation are not a reasonable replacement for careful risk analysis by the business done by people who are familiar with the business.

Step # 1- Do not do an expensive business process mapping project.

Many consultants tell organizations that they must perform a detailed business process analysis and build data flow diagrams of data and users who process data. This is an expensive task to execute and extremely difficult to maintain that can require large quantity of billable hours. That’s why they tell you to map data flows. The added value of knowing data flows inside your organization between people doing their job is arguable. There are much better ways to protect your data without writing out a 7 digit check. Here is the first one you should try out. Select the 10 most valuable data assets that your company owns. For example – proprietary mechanical designs of machines, detailed financials of a private company being acquired, and details of competitive contracts with large accounts. In a few interviews with finance, operations, IT, sales and engineering, you can nail down those key assets. After you’ve done that, schedule a 1 hour meeting with the CFO and ask her how much each asset is worth in dollars. In general, the value of a digital, reputational, physical or operational asset to a business can be established fairly quickly by the CFO in dollar terms – in terms of replacement cost, impact on sales and operational costs.

Step #2 – Do not develop a regulatory compliance grid.

There is no point in taking a non-value-added process and spend money making it more effective.

My maternal grandmother, who spoke fluent Yiddish would yell at us – ” grosse augen” when we would pile too much food on our plates. ” Grosse augen” ( or as my folks put it); is having eyes that are bigger than your capacity. Yes, US publicly traded companies are subject to multiple regulations – if the company sells to customers and stores and processes PII (personally identifiable data) they will have to deal with PCI DSS 1.1, California State Privacy Law, Sarbanes-Oxley PCI DSS 1.1 protects one asset – payment card numer and magnetic stripe, while Sarbanes-Oxley is about accounting records. Yes, there are a few commercial software products that map business processes, databases and data elements to multiple regulations; their goal is to help streamline the work involved in multiple regulatory compliance projects – eliminating redundancy where possibility using commonality.
Looking at all the corporate governance and compliance violations; cases such as Hannaford supermarkets and AOL – it’s clear government regulation has not made America more competitive nor better managed.

Step #3 – Identify the top 5 data assets in your business and valuate them

I saw an article recently that linked regulatory compliance mandate and asset cost. Definitely not true – the value of an asset for a company is whatever operational management/CFO say it is. Asset value has nothing to do with compliance but it has everything to do with a cost effective risk control plan. For example – a company might think that whole disk encryption on all company notebook computers is a good idea – but if only 20 people have sensitive data – why spend 1 million dollars on mobile device data encryption when you can solve the problem for less than 5k?

Step #4 – Do not store PII

The absolutely worst thing you can do is a project to analyse data retention and protection regulations that govern each of the sensitive data elements that need protecting, and working with legal and compliance consultants who know the relevant regulations. VISA has it right. Don’t store credit cards and magnetic strip data. It will not help the marketing guys sell more anyway – and you can give the money you save on some fancy database encryption software to the earthquake victims in Myanmar and China.

Step #5 – Monitor your outsourcing vendors

Despite the hype on trusted insiders, most data loss is from business partners. You can write a non-disclosure agreement with an outsourcing vendor and trust them, but you must verify their compliance and prevent unauthorized data leaks.

The best story I had in years was in a meeting with the VP internal audit at a medium sized bank in Israel. He took a sales call with me and I pitched our extrusion prevention technology from Fidelis Security Systems as a way to protect their customer data. He said – look Danny, we don’t need technology – we’ve outsourced everything to a very large bank and their data center security is world-class. Two weeks later, the big bank had a serious data breach event (a high school student hacked into the internal network of the bank from a public Windows-based kiosk and helped himself to some customer lists. Two months later, the small bank was reported to be looking to get out of their outsourcing contract. Don’t rely on contracts alone – use people and DLP technology to detect data leakage.

Step #6 – Do annual security awareness training but keep it short and sweet

Awareness is great but like Andy Grove said – “A little fear in the workplace is not necassarily a bad thing”. Have everyone read, understand and sign a 1 page procedure for information security. Forget interview projects and expensive self-assessment systems – what salesman in his right mind will take time to fill out one of those forms – if he doesn’t update his accounts on salesforce.com? Install an extrusion detection system at the network perimeter. Prosecute violators in real time. Do random spot checks on the read-and-understand procedure. Give demerits to the supervisors and managers if their employees don’t pass the spot check.

Step #7 – Calculate valuate at risk of your top 5 data assets

ISO 27001 and PCI DSS 1.1 checklists are great starting points but they focus on whether a particular technology, policy or control has been implemented, and not whether these controls are cost-effective security countermeasures against internal and external attackers. Use Practical Threat Analysis with a PTA risk library for ISO 27001 or PCI DSS 1.1 and you will be able to build a cost-effective risk mitigation plan based on asset values, threat probabilities and estimated damage levels.

Step #8 – Ask your vendors and colleagues difficult questions

After you’ve done a practical threat analysis of your risk exposure to attacks on sensitive customer data and IP you will be in better position than ever to know what policies, procedures and technologies are the most effective security controlss. You’ll be in an excellent position to ask difficult questions and negotiate terms with your favorite vendor. While the attitude of many companies is to hold data protection protections close to their chests, it is valuable to talk to your colleagues at other companies in the same market and get a sense of what they have done and how well the controls perform.

Step #9 – Resist the temptation to do a customer data integration (CDI) project.

Customer data is often stored in many applications and locations in a large organization. The knee-jerk reaction of IT is to do a big data integration project and get all the digital assets under one roof. There are three reasons why this is a terrible idea. (a) Most of these projects fail, overrun and never deliver promised value (b) If you do suceed in getting all the data in one place, it’s like waving a huge red flag to attackers – heah , come over here – we have a lot of sensitive data that is nicely documented and easily accessible. Companies with enterprise software systems such as SAP and Oracle Applications are three times more likely to be attacked. (c) Ask yourself – would Google have succeeded if with global data integration strategy?

Step #10 – Prepare a business care for data loss prevention before evaluating products

Despite claims that protecting data assets is strategic to an enterprise, and IT governance talk about busines alignment and adding value – my experience is that most organizations will not do anything until they’ve had a fraud or data security event. The first step to protecting customer data and IP in any sized business from a individual proprietership to a 10,000 person global enterprise is laying the case at the door of the company’s management. This is where executives need to take a leadership position – starting with a clear position on which data assets are important and how much they’re worth to the company.

Practical threat analysis is a great way to identify and assess threats to your business and evaluate the potential business impact in dollars and cents to your operation using best-practice risk models provided by the PTA Professional threat modeling tool.

In summary

Software Associates specializes in helping medical device and healthcare software vendors achieve HIPAA compliance and protect customer assets and provides a full range of risk management services, from stopping fraud to ensuring regulatory compliance and enhancing your ability to serve your customers.

There are resources that help you turn information into insight such as   Risk Management from LexisNexis, Identity Fraud TrueID solutions from LexisNexis that help significantly reduce fraud losses and Background Checks from LexisNexis that deliver valuable insights that lead to smarter, more informed decisions and greater security for consumers, businesses and government agencies.For consumers, its an easy way to verify personal data, screen potential renters, nannies, doctors and other professionals, and discover any negative background information that could impact your employment eligibility. For businesses and government agencies, it is the foundation of due diligence. It provides the insight you need to reduce risk and improve profitability by helping you safeguard transactions, identify trustworthy customers and partners, hire qualified employees, or locate individuals for debt collections, law enforcement or other needs.

 

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