Tag Archives: Application security

hipaa cloud security

WannaCrypt attacks

For your IMMEDIATE notice: If you run medical device Windows management consoles, run Windows Update and update your machine NOW. This is my professional advice considering the new ransomware worm out there attacking machines

MS17-010 has been out more than a month, but we have to assume that that the majority of Windows-based medical devices and Windows-based medical device monitoring platforms are vulnerable.

 For Windows XP, Windows 8, and Windows Server 2003 systems,  the patches still aren’t available though windows update – you need to get them from https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ and deploy manually.

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

Why Microsoft Windows is a bad idea for medical devices

I’m getting some push back on LinkedIn on my articles on banning Microsoft Windows from medical devices that are installed in hospitals – read more about why Windows is a bad idea for medical devices here and here.

Scott Caldwell tells us that the FDA doesn’t rule “out” or “in” any particular technology, including Windows Embedded.

Having said that, Microsoft has very clear language in their EULA regarding the use of Windows Embedded products:

“The Products are not fault-tolerant and are not designed, manufactured or intended for any use requiring fail-safe performance in which the failure of a Product could lead to death, serious personal injury, severe physical or environmental damage (“High Risk Activities”).”

Medical device vendors  that  use Windows operating systems for less critical devices, or for the user interface are actually increasing the threat surface for a hospital, since any Windows host can be a carrier of malware that can take down the entire hospital network, regardless of it’s primary mission function, be it user-friend UI at a nursing station or intensive care monitor at the bedside.

Medical device vendors that use Microsoft IT systems management “best-practices” often  take the approach of “bolting-on” third party solutions for anti-virus and software distribution instead of developing robust, secure software, “from the ground up” with a secure design, threat analysis, software security assessment and secure software implementation.

Installing third-party security solutions that need to be updated in the field, may be inapplicable to an embedded medical device as the MDA (Medical Device Amendments of 1976) clearly states:

These devices may enter the market only if the FDA reviews their design, labeling, and manufacturing specifications and determines that those specifications provide a reasonable assurance of safety and effectiveness. Manufacturers may not make changes to such devices that would affect safety or effectiveness unless they first seek and obtain permission from the FDA.

It’s common knowledge that medical device technicians use USB flash drives and notebook computers to update medical devices in the hospital. Given that USB devices and Windows computers are notoriously vulnerable to viruses and malware, there is a reasonable threat that a field update may infect the Windows-based medical device. If the medical device is isolated from the rest of hospital network, then the damage is  localized, but if the medical device is networked to an entire segment, then all other Windows based computers on that segment may be infected as well – propagating to the rest of the hospital in a cascade attack.

It’s better to get the software security right than to try and bolt in security after the implementation.Imagine that you had to buy the brakes for a new car and install them yourself after you got that bright new Lexus.

It is not unusual for medical device vendors to fall victim to the same Microsoft marketing messages used with enterprise IT customers – “lower development costs, and faster time to market” when in fact, Windows is so complex and vulnerable that the smallest issue may take a vendor months to solve. For example – try and get Windows XP to load the wireless driver without the shell.   Things that may take months to research and resolve in Windows are often easily solved in Linux with some expertise and a few days work. That’s why you have professional medical device  software security specialists like Software Associates.

With Windows, you get an application up and running quickly, but it is never as reliable and secure as you need.

With Linux, you need expertise to get up and running, and once it works, it will be as reliable and secure as you want.

Yves Rutschle says that outlawing Microsoft Windows from medical devices in hospitatls  sounds too vendor-dependant to be healthy (sic) (Seems to me that this would make the medical device industry LESS vendor-dependent, not more vendor-dependent, considering the number of embedded Linux options out there.)

Yves suggests that instead, the FDA should create a “proper medical device certification cycle. If you lack of inspiration, ask the FAA how they do it, and maybe make the manufacturers financially responsible for any software failure impact, including death of a patient“. (The FDA does not certify medical devices, they grant pre-market approval).

I like a free market approach but consider this:

(Held)The MDA’s pre-emption clause bars common-law claims challenging the safety or effectiveness of a medical device marketed in a form that received premarket approval from the FDA. Pp. 8–17.

Maybe the FDA should learn from the FAA but in the meantime, it seems to me if the FDA pre-market validation process had an item requiring a suitable operating system EULA, that would pretty much solve the problem.

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

What do hackers want?

What do hackers really want?

No question is more important for mounting  effective security countermeasures. The management, IT and security practitioners cannot expect to mitigate risk effectively without knowing the objectives and cost of potential attacks on their organization.

We all depend on transaction processing to run our business and make decisions, no matter how big or small we are. We all use business applications (most of them Web-based these days) to buy, sell, pay vendors and collect from customers.

The prevailing security model predicates defense in depth of transaction systems. The most common strategies are to mitigate risk with network and application security products that are reactive countermeasures; blocking network ports and services, detecting known application exploits, or by blocking entry of malicious code to the network.

Are any of these security countermeasures likely to be effective in the long-term? Can attacks on a business be neutralized with defensive means only? In other words, is there a “fire and forget” security solution for the business? The answer is clearly no.

This is for three reasons:

  1. You must understand the attacker. If you understand what a terrorist wants (suicide bomber in a shopping mall sometime next week),  you can save lives with a preemptive attack. In the physical world – we defend the citizens of our country with both defensive and offensive means.  Often a political decision that is up for public scrutiny and criticism, nonetheless we do attack our enemies – with military action; commando raids, precision bombing or carpet bombing.
  2. You must understand yourself. Defensive “fire-and-forget” security countermeasures such as an IPS are not a replacement for understanding of where the threats lie and how much your assets are worth. A  Checkpoint SmartDefense firewall can help protect against malformed IMAP commands but  it cannot detect extrusion of proprietary company assets in a gmail attachment. An application firewall can help mitigate well-known XSS vulnerabilities but won’t fix bugs in customized application source code or mend system configuration problems.
  3. You must consider the alternate cost. There is no reason for us to attempt to take rational decisions in the real world but abstain from cost-benefit calculations in the cyberspace.  The cost of mounting a cyber attack on a company, bribing/social-engineering an employee to mail a file with all employee details is far less than what the company spends on its information security systems. With  inherently asymmetrical costs of cyber defenses versus cyber attacks, it’s high time to change the rules. Robert Bejtlich has a fascinating discussion on his blog – Mutually Assured DDOS. It’s a catchy title with a lot of interesting insights – but personally – I am not sure that projection of power and deterrence and mutually assured destruction is an acceptable corporate or government business objective.
Tell your friends and colleagues about us. Thanks!
Share this