Author: Dr. Philip Cao

Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
Posted on

Trusting the Cloud: HIPAA Risk Assessment for Cloud-Based Files

Cloud-based computing and storage is increasingly popular—to the extent that some companies are cutting hard drive space to encourage users to shift toward the cloud. And while the cloud is convenient, allowing your files to travel easily and across devices, that kind of convenience isn’t exactly what you want when it comes to protecting medical files. Is your cloud use secure enough to meet Health Insurance Portability and Accountability Act (HIPAA) standards? Here are some factors to consider.

A Quick Overview
There are a lot of cloud systems available these days, but the first thing you should do when choosing one is compare baseline HIPAA compatibility. Amazon S3, Dropbox and iCloud are not compatible with HIPAA practices out of the box. Most other major systems, including Box, Egnyte, Google apps, and CrashPlan Pro are HIPAA compliant. Identifying the outsiders reduces your choice of cloud systems, allowing you to focus in on the details of compliant plans.

EHR or HIPAA
In addition to cloud computing, many physicians are shifting to digital recordkeeping, using what are known as electronic health records (EHR) systems. These systems are great for centralizing patient data and encouraging collaboration across different medical practices that share the same EHR vendor. However, EHR requirements and HIPAA privacy standards aren’t exactly the same.

The first rule of managing EHR in accordance with HIPAA standards is that you should never trust an EHR vendor that says you don’t need to worry about their HIPAA compliance. Although your specific files may be HIPAA compliant, other practices used by external vendors may not be; for instance, their cloud storage security may be lacking. Additionally, although EHR systems have all the features needed to be fully HIPAA compliant, you’ll need to check to make sure they are properly configured. If necessary safeguards are turned off, your patients’ data may be at risk.

Don’t Play Hide and Seek
Rather than establishing thorough HIPAA compliant practices, some organizations still think that what is known as “security through obfuscation” is a valid system providing the necessary protections. Realistically, though, this is possibly the worst of all security practices. This kind of security focuses on hiding your computer network, but tends to disregard proper antivirus software.

Additionally, such practices tend to reveal other lacking security practices within the organization, such as indiscriminate file sharing (between virus-infected computers, no less). Simply hiding your network doesn’t count as securing your files – a skilled hacker can easily access even an invisible network.

BAAs Are Not Enough
Google has a great reputation in the cloud-computing world, and with health organizations with high security standards. This means that medical practices using Google apps often feel confident that their files are safe, as long as they’ve signed a Business Associate Agreement (BAA).

BAA agreements might keep your information safe on an internal level, but this agreement won’t help secure patient files when transferred to other digital environments. Instead, when transferring files, using end-to-end encryption is the safest bet. This system will keep your data HIPAA compliant, even when it leaves the Google cloud.

Consider Adoption Side Effects
It’s great to choose a new HIPAA-compliant cloud system for your business, but in our pursuit of better data management systems, we often forget to consider the human elements of adopting new systems. Before choosing a new system, then, it’s important to ask whether your employees will be able to effectively use the new system, and whether there are other options they may find more convenient.

This is a common problem for companies choosing between Office 365 and Google apps for their cloud computing activity. Both Microsoft and Google will sign BAAs that offer HIPAA compliance, but the two programs have different strengths. This is where considering use and convenience is important. If you work a lot with documents, you might think that Office 365 is the way to go—most of us came of age writing everything in Word, so why not? The main reason not to, it seems, is that Google Docs’ collaboration systems are helpful and the platform is more convenient. The reverse seems to hold for spreadsheets.

If you can’t get your team on board with a new computing system, no amount of security regulation in the world will help you. Be sure to clearly to tell your staff about organizations with which you have BAAs, the legal risks of using other systems, and their responsibility to patient privacy as health field employees.

Larry Alton
Writer
[ISACA Now Blog]
Posted on

Healthcare Organizations: How to Get Ahead of Unapproved Cloud-Based File-Sharing Tools

Cloud-based file-sharing tools such as Box, Dropbox, SugarSync and Google Drive can cause major security issues for healthcare organizations. And as a former security lead for a hospital, I found that, even if you have an approved cloud file-sharing website, unless you block access to non-approved file-sharing sites, medical practitioners will use whatever they personally prefer to share protected health information (PHI) with colleagues. Your organization may be deploying Box for internal hospital use, for example, but some doctors will still prefer to use Dropbox to store and share PHI – it’s not enough to deploy one approved tool and then hope for the best.

Once you upload PHI data to a popular cloud file-sharing sites, it’s very easy to (mistakenly) configure it to be accessible to everyone on the Internet. As you can see in this screenshot of the free version of Dropbox, users do not have the ability to restrict access to specific users. The only option for controlling view access to their file is to select “Anyone with the link” as shown below. This means that if the link is posted to a Reddit conversation or another public forum, anyone would be able to download the files.

Palo Alto Networks is often asked to perform free proof-of-concept exercises at hospitals and other healthcare organizations, and I have found that it is quite common to find web access is enabled to unapproved cloud file-sharing sites.

When I led the effort to disable access to cloud file-sharing sites in my former role, I knew that I couldn’t simply block all access without a careful plan. If I had done so, I would have been inundated with tickets from angry doctors wondering what was going on. The reality is that there are likely to be business processes that impact patient care that rely on access to these sites. For this reason I recommend the following high-level plan to decommission access to unapproved cloud file-sharing sites while making sure that clinical processes are not impacted:

  1. Confirm CISO/CIO support of your effort to block cloud file-sharing sites.
  2. Verify that you have approved alternatives to commonly used, but insecure cloud file-sharing sites. Users will need help to migrate their processes to the approved solution.
  3. Determine the users who are accessing cloud file-sharing sites (if you have the capability).
  4. Email users a warning that access to cloud file-sharing sites will be blocked on such and such a date.
  5. Instruct users to open a ticket with the IT Security team to understand approved file-sharing alternatives.
  6. Document a process for approving exceptions, and ensure that exceptions are revisited at least every six months. Require CISO approval for exceptions.

Healthcare organizations can safely enable access to sanctioned cloud file-sharing sites with careful planning and the right security tools, but any such website that is not explicitly approved by the organization should be blocked to avoid HIPAA-reportable incidents – as soon as possible.

Learn more about Palo Alto Networks solutions for sanctioned SaaS applications and next generation security in healthcare organizations.

[Palo Alto Networks Blog]

Posted on

Palo Alto Networks Lauded for Outstanding Customer Support by TSIA and J.D. Power

The Technology Services Industry Association (TSIA) and J.D. Power have recognized us for our ability to deliver exceptional customer support to our customers. These prestigious industry awards include the TSIA Star Award in 2014 for Innovation in the Delivery of Support Services, TSIA Worldwide Rated Outstanding Assisted Certification and, most recently, Palo Alto Networks, North America Assisted Support, has been recognized by J.D. Power for providing outstanding customer service for its Assisted Technical Support.

Read on for details:

2015 J.D. Power Certified Assisted Technical Support Program

Palo Alto Networks is the first to have achieved the 2015 Certified Assisted Technology Support (CATS) Certification under this new program from J.D. Power for providing exceptional commitment and support to our customers.

Palo Alto Networks, Inc. North America Assisted Support has been recognized by J.D. Power for providing outstanding customer service for its Assisted Technical Support

J.D. Power 2015 Certified Assisted Technical Support Program, developed in conjunction with TSIA. Based on successful completion of an audit and exceeding a customer satisfaction benchmark for assisted support operations. For more information, visit www.jdpower.com orwww.tsia.com.

2015 TSIA Global Rated Outstanding Assisted Certification

TSIA certification recognizes that Palo Alto Networks has achieved Global Rated Outstanding Assisted Support. Customers can purchase Palo Alto Networks products with confidence knowing that Palo Alto Networks meets the highest industry support standards.

2014 TSIA Star Award for Innovation in the Delivery of Support Services

This award recognizes the company that has embraced innovation in people, process and technology to increase agent productivity, service levels or customer satisfaction; increase problem avoidance; or effectively handle more interactions using unassisted channels.

To read more about these accolades, please visit:

Palo Alto Networks takes great pride in delivering an exceptional customer experience, and we are very proud to receive recognition from both TSIA and J.D. Power. We will continue our commitment to delivering an exceptional support experience for our customers.

Please let me know if you have any comments or questions, or contact me via Twitter anytime at @CicconeScott.

[Palo Alto Networks Blog]

Posted on

Step-By-Step: Using AutoFocus API and Postman for Automation

One of the important components baked into the Palo Alto Networks next-generation security platform is our API. You can use our API to interact with and automate the various components of our platform, such as bulk searches, push and pull configurations, leveraging third-party applications and services, and more.

In this post, I’ll explain, step-by-step, how to use our API with AutoFocus utilizing the Postman app. Postman is a useful development and testing client for REST API, creating complex HTTP requests and giving you the ability to interact with the API as it presents a friendly GUI for constructing requests and for reading responses. We’ll be using this application to demonstrate Palo Alto Networks AutoFocus API capabilities.

Prerequisites

Before you can start using the AutoFocus API, there are a few steps needed to ensure things run smoothly:

  • Make sure you have portal access credentials to AutoFocus (Contact your Palo Alto Networks representative or partner if you’d like to purchase or trial AutoFocus)
  • Get your API Key (use the API Key process to obtain one)
  • Get familiarized with the AutoFocus portal and read our AutoFocus Administrator’s Guide
  • Brush up on your knowledge of web service APIs, HTTP, and JSON.
  • Install the Postman app

NOTE: Take the following steps if you already have access to the AutoFocus portal and want to retrieve your API Key:

Making your API Call

In this example, we want to find all the Dridex instances in our network that WildFire convicted as malware and where the destination files are the United States. We want those results in JSON format so we can use this data any way we want: parse it, use parts of it, export it to third-party-services or applications, or integrate the information into the SOC.

Many of the resources in the AutoFocus API require API calls to two resources. The first call is to initiate a search and the next is to check for the results of that search. Take the following steps to configure the Postman Application.

Step 1: Configuring the search query

As mentioned before, you need to craft two API calls to two different resources. The first call is the query itself to pull the data and the second one is to fetch and present the results. Both calls use the POST method. Crafting the AutoFocus query itself can get complicated depending on the query you want to design.

The best way to create your own query is to use the AutoFocus search option and then export the query into a file using the following process:

  • Log in to the AutoFocus portal
  • Create the query as described

  • Use the export option to export your search

  • You can then copy the search or save it to a file and use it later when you need it

As a side note, the same rule applies when you want to create an API call using a shell/python script using the CLI instead of the Postman Application.

For the first call:

  • Configure Postman POST method to communicate to:https://autofocus.paloaltonetworks.com/api/v1.0/samples/search/
  • Choose the “raw” option under the “Body” tab
  • Select the JSON (application/json) output
  • In the query field, use the API Key you copied into the “apiKey”: “XXXXX”
  • Type in the query and click the “Send” button

  • If everything went well and the apiKey value you have entered is correct, you will get the query result values in the results window.
  • The specific value you need to look for is the af_cookie. Once you find it, copy the value.
  • The af_cookie expires 120 seconds after the search results are complete (when af_complete_percentage is 100) or after you view completed search results.

Step 2: Viewing the Results

To view the results and retrieve the af_cookie, you need to configure Postman to perform the second POST method and point it to the results link.

You should be able to view the output in the results/output window at the bottom of the Postman Application.

Then copy and search the results you pulled from AutoFocus. You can also save the output to a file and perform regular expression and parsing as needed, export the data, etc…

Conclusion

This was just one example of the different ways you can leverage and use the AutoFocus API to perform automation and link between various third-party-tools and streamline your threat

intelligence analysis, perform bulk searches, import and export queries, leverage IOC, and so on. AutoFocus is a powerful tool for performing threat intelligence, leveraging the rich data Wildfire provides and shortening the analysis time needed to reach a quicker resolution and root cause analysis. By adding the power of the API, you achieve integration and automation between the Palo Alto Networks platform and your existing infrastructure, further streamlining analysis and getting the results you need, quickly and easily.

For more information, visit the AutoFocus API website to find different examples, configurations, prerequisites, rate limits, and other resources.

[Palo Alto Networks Blog]

Posted on

As Usual, Attackers Were Busy Over the Holiday Season

The holiday season is a time for friends and family, as well as for heightened levels of consumer shopping. It’s also a time of year when threat actors get especially opportunistic, and the 2015 holiday season was no different.

Let’s take a closer look at recent holiday season-themed attacks.

Happy Festivus!

Unit 42 examined the time period from November 25, 2015 through December 29, 2015 and identified nearly 4 million phishing attacks containing malicious attachments using AutoFocus. Out of these phishing email messages, we then searched specifically for holiday-themes, using keywords such as “Christmas,” “holiday,” “Santa,” etc. Amongst the results, 92 percent of the attacks identified to be holiday themed were already found to have a Unit 42 tag associated with it, providing additional context around the malware family in use, indicator sets, and any references that may be of use.

It’s important to note that we did not include keywords related to “package delivery notification” themes in this analysis. While these can certainly be characterized as holiday-related, we find these themes are abused year-round by attackers and no longer specific to the holiday season.

Among the observed sessions positively identified as holiday-themed, a single organization in higher education generated the significant majority, roughly 80 percent of those sessions, primarily containing the Bartallex/Dridex macro malware families delivering payloads containing Pony, Rodecap, and Zeus.

This data seems to indicate that a significant campaign was put in place at the affected organization, and the adversaries specifically leveraged holiday themes in an attempt to attack as many victims as possible. Subject lines for the phishing lures were made up of mostly shopping-related topics, such as advertisements for sales or giveaways. Other lures included invitations to holiday festivities; simple greetings or well wishes; and, strangely, alcohol addiction-themed lures.

Other industries did experience similarly themed attacks, but not in nearly as high volume as higher education due to the one largely affected organization.

Figure 1 Holiday-Themed Phishing Attacks by Date

Figure 1 shows the general trend of holiday-themed phishing attacks, which loosely corresponds to work weeks (little to no activity on Friday, Saturday, and Sunday), as well as the tapering off in activity as workers began to take days off for the holidays.

Examining the possible motivations by the adversaries involved in holiday-themed attacks, the vast majority appear to be motivated by profit – cybercriminals seeking to generate revenue using malware, such as banking Trojans designed to steal credentials, botnet malware that causes the victim to unwittingly join a botnet often put up for sale, and ransomware that can encrypt a victim’s data and hold it hostage.

The most common delivery methods used a weaponized Microsoft Office document using a macro, or macro malware, to retrieve additional malware once launched on the victim host. These generally fell under the Dridex or Bartallex families and made up 50 percent of all holiday-themed malware. Other delivery mechanisms were generally much simpler, arriving in the form of a portable executable attachment in a holiday-themed email message with the hope that a victim would launch it.

Figure 2 Breakdown of malware families

“WISH U A MERRY CHRITMAS DAY”

Although most of the activity of holiday-themed attacks appeared to be for-profit, at least one targeted attack was observed during the season. The attack used a malicious RTF file exploiting an older, but well-known vulnerability in Microsoft Word, CVE-2012-0158. This vulnerability has been exploited in multiple cyber espionage operations, including Lotus Blossom, but does not indicate an attack by any particular group. The malicious document contained a Christmas-themed graphic (Figure 3) and used a Christmas-themed filename, “Christmas Letter&sponsors.doc.”

Once executed, the file would drop a self-extracting RAR file containing a legitimate executable that would then be used to sideload malicious DLLs. The malware ultimately installed onto the victim host has been identified as LURK0, a variant of the well-known Gh0st RAT. Gh0st RAT is a fairly old, but effective remote access Trojan, and the source code is freely available on the Internet. Because of this, it is quite popular and has been observed in use by multiple nation-state groups as well as cybercriminals. Additionally, the variants and modifications to the original source code are numerous. The one constant of Gh0st and its variants is their network communications – they always begin with a “magic word,” using “Gh0st” in the default configuration. Roughly 50 or so magic words have been discovered, with each variant being named after that magic word. This particular sample uses “LURK0” as the magic word, hence the name.

Figure 3 Image from Weaponized RTF

Conclusion

As we have indicated in multiple previous blog articles, staying situationally aware of ongoing events in our everyday lives is vital in effective defense against the adversary. For specifically holiday-themed attacks, the motivations appear primarily profit-driven. The holiday season can be a high-stress time, and consumers may be more likely to pay an adversary if, for example, their data was encrypted by ransomware. There may also be a higher level of banking activity as funds are transferred and exchanged at a higher volume due to the additional shopping that occurs. Of course, that does not mean targeted attacks leveraging this seasonal event do not occur, as described previously.

Ultimately, the overall trend continues: our end users are constantly faced with a barrage of attacks on both their personal and professional resources. Taking a prevention-first approach to security is crucial in reducing the attack surface to more effectively defend ourselves and our organizations from all adversaries.

[Palo Alto Networks Blog]

English
English
Exit mobile version