STE WILLIAMS

Much has been made of the need to share information among companies since President Clinton signed Presidential Directive 63 exactly 20 years ago today, on May 22, 1998. Commonly referred to as PDD-63, the directive called for the creation of information sharing and analysis centers (ISACs) for critical sectors of the economy. President Obama widened the aperture to include other constituencies that desired to work together, including small businesses, sports organizations, and Internet of Things communities. Congress stepped up and passed the Cyber Security Act of 2015, which clarified what information can (and cannot) be shared and relieved concerns about liability and antitrust.

But even with all of this activity, progress has been very slow. Robust organizations like the FS-ISAC have been established to address sharing within the financial sector, but most organizations would agree that we have struggled with the “what, when, and how” of information sharing. In fact, the use of the word “sharing” in cybersecurity has almost become pejorative. Very basic questions have surfaced within in small and large organizations, such as, “How do I decide what to share?” “Do I only need to share information after a breach?” “How do I share securely?” and perhaps most importantly, “What value will I receive in return?”

Prior to the anniversary of PDD-63, the Cloud Security Alliance (CSA) with little fanfare made a significant contribution to enabling the free flow of sharing by releasing a research paper on its experiences in operating the Cloud Cyber Incident Sharing Center (C-CISC). The organization’s work started nearly two years ago when Jim Reavis, CEO of CSA, started a voluntary exchange among member companies to exchange data. CSA member experiences yielded some straightforward lessons that can be adopted by ISACs and individual organizations alike.

Fixing a Broken Information Sharing Process
First, we must acknowledge there are vast differences between legacy information sharing systems and what organizations should look for today. The working group discovered that many organizations would hold data until after a breach was confirmed, which is of little value to others seeking to prevent a similar attack. Most data was being shared through noisy email listservs, and the review and approval process for sharing data was burdensome, resulting in reports that lacked proper context.

Through trial and error, CSA discovered what to share and how to share and identified key technologies to automate redaction and protect privacy.

The Hardest Part Is Getting Started
CSA’s working group also found the majority of enterprises it encountered wanted to participate in a threat intelligence exchange, but they didn’t know where to start. Enterprises begin by leveraging events generated by security information and event management systems or other tools that require review by an analyst. Then they gather event data with context into a secure repository, and, finally, exchange data with others using automated redaction tools.

CSA learned that most organizations did not have the means to see all of their suspicious event data in a common repository. In some cases, organizations were using multiple case management or orchestration tools that did not allow for easy correlation or real-time chronology of event data. The CSA guidance advises to select a system that allows the user to receive immediate feedback and is extensible, allowing you to choose what you want to share and with whom.

CSA’s research paper includes other useful guidance around developing supporting security knowledge management policies and helps shape organizations that are thinking about evolving to mature cyber intelligence knowledge management, rather than thinking about purely reactionary threat intelligence as we did in the wake of breaches against Target and others several years ago.

Twenty years is far too long to wait for such guidance, but it has arrived just in time. You can download the paper here.

Related Content:

• 7 Tools for Stronger IoT Security, Visibility
• A Pragmatic Approach to Fixing Cybersecurity: 5 Steps
• Congress Clears Path for Information Sharing But Will It Help?

Paul Kurtz is the CEO and cofounder of TruSTAR Technology. Prior to TruSTAR, Paul was the CISO and chief strategy officer for CyberPoint International LLC where he built the US government and international business verticals. Prior to CyberPoint, Paul was the managing partner … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/the-state-of-information-sharing-20-years-after-the-first-white-house-mandate/a/d-id/1331849?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

In a future where everything is connected, cybercriminals may not need to target you to steal your personal data. They can hack your pets instead. 

Kaspersky Lab researchers today published the results of a study investigating vulnerabilities in popular pet trackers, which transfer GPS coordinates from pets to owners for safety and location monitoring. The flaws they discovered could let an attacker hack these devices, identify and replace the coordinates of a pet and its owner, and access owners’ data.

In studying several brands of pet trackers, researchers found: Bluetooth capabilities that don’t require authentication, authorization tokens and coordinates that can be stored sans encryption, trackers that don’t check server certificates for HTTPS connections, and trackers and apps that allow the installation of false firmware and transmit the name, email, and coordinates of the pet’s owner.

It’s another reason to worry about the implications of poor IoT security. If a hacker can intercept these coordinates, they can identify where a pet or owner is at any given time, learn their daily routines, and over time develop a pattern of owners’ and animals’ habits.

Read more details here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/endpoint/pet-tracker-flaws-expose-pets-and-their-owners-to-cybercrime/d/d-id/1331866?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A newly announced vulnerability in iOS (and, just maybe, Android) could be an avenue for exploitation through misbehaving apps. The vulnerability, named “ZipperDown” by Pangu Lab, is described as a “common programming error” by the researchers — so common, in fact, that the team estimates 15,978 out of 168,951 iOS apps (or nearly 10% of the total) are affected.

So far, Pangu Lab has not released details of the vulnerability to the public, though they are working with app publishers thought to be affected. The good news is that ZipperDown seems to require at least a couple of unusual conditions for an exploit to occur: The first is that the attacker must control the WiFi network to which the device is connected. Next, the app in question must be running outside the iOS “sandbox.”

If those two conditions are met and the vulnerability is exploited, it could allow a hacker to run illicit applications on the affected device. While an Android vulnerability to the issue has not been formally confirmed, Pangu Lab says that the conditions for exploit exist and they will issue an additional report in the near future.

While the conditions for successful exploit are limited, the sheer number of apps affected make this a vulnerability developers are taking seriously in spite of (or perhaps due to) its name.

Pangu Lab has released a video showing the exploit:

For more, read here and here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/endpoint/zipperdown-vulnerability-could-hit-10--of-ios-apps/d/d-id/1331867?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

While there has been a lot of chatter about the magnitude of penalties organizations may find themselves hit with (up to €20 million in fines) under the impending General Data Protection Regulation (GDPR), there isn’t nearly enough talk about how to avoid penalties in the first place.

Sure, there are conversations about pre-ticked opt-in boxes and breach notification protocols (“You have 72 hours to report personal data breaches to the appropriate authorities,” for one). But businesses are failing to address the root of the problem — the data itself.

To ensure compliance with GDPR, personal data must be kept only for as long as necessary, an issue that clearly is up for debate, as length of time varies by organization and industry. Then there is the “right to be forgotten,” which means that data subjects can request that their data be deleted at any time.

But to understand how to identify, recall, and protect that data, organizations must first understand the nature of the data itself. For example, if I, Marc French, log in to your website, you need to keep track of where I go — and in a timely manner. If I ask for you to remove my data so the Googles and Facebooks of the world can’t access bits and pieces of my “identity,” you’re now obligated by law to destroy any trace of it. And, if you don’t know where that data is, you can’t get rid of it.

Whether it’s in the finance department’s hands, the marketing department’s in-boxes, or even with your shipping company for deliveries, there are a lot of different parties that are constantly using, holding, and updating personal data. That’s why it’s important to look at the data custody process in terms of tiers and outside forces — a supply chain, essentially.

Here are three examples of supply chain data you might not be considering but that could have GDPR impacts:

1. Escalation personnel phone numbers of your European IT staff for the cloud service to which you subscribe. Phone numbers are personal data, and you need to ensure that they do not leave the cloud service to its downstream partners without your consent.

2. The event registration data you collected for that big marketing conference that includes dietary restrictions for attendees. Not only is the attendee registration data considered personal data, but you are now also collecting sensitive medical data by way of the dietary restrictions. Because of this, you need to track what the caterer is doing with the information that is provided.

3. Your building’s security desk that signs in visitors to your office, prints a badge, and gives it to the visitor, who later returns it upon leaving. Not only is data on the badge likely personal, but how you dispose of it, or how the security vendor handles it in its system, has GDPR implications.

As you can see with data collection, retention, and processing, there are a lot of moving pieces involved, and each of these parties comes into contact with personal data at some point along the line. Because of this, there’s now a responsibility for both data processors (such as service providers) and data controllers (such as your organization) to work together in the case of a breach under GDPR.

According to the regulations, both parties might be liable for breaking the law and are required to notify regulators, their customers, and end users, and, ultimately, both parties are obligated to pay all fines and compensate customers for damages. If anyone in your supply chain loses control of the data, you too may also be responsible — and experience both pricey financial and reputational costs.

Before you develop a plan for working with the different tiers, the first step will be to consider how you classify the data. It’s important that you qualify the data you collect and determine its value/risk to the business before doing anything else. For example: Is the data critical to your revenue stream (credit card data), or would the loss of the data be catastrophic to your intellectual property strategy (formula to your specialty cola)? If so, you rate the risk/value high.

Next, you’ll need to rank your vendors. Ask employees who are provisioning new vendors what data they are collecting, and then rank the vendors based on the data valuation you developed during step one. They’ll typically be split into two levels, which many organizations break down as:

Tier 1: Vendors that operate on the most sensitive data you have. You will want to do a dive deep with these folks and conduct a thorough vendor review, ensure contractual protections, and regularly review them for compliance and security.

Tier 2:  These vendors may operate on less sensitive data. Keep track of these folks in a central system on a regular schedule, so you can dust the list off and sample your internal customers to see if they are using additional services that might elevate them to tier 1. You may be surprised that the tier 2 vendor you set up two years ago has become tier 1 as the partnership has evolved.

With the GDPR deadline upon us, it is important to start work closely with tier 1 and tier 2 vendors to guide your organization’s data protection strategy moving forward.

Related Content:

• GDPR Compliance: 5 Early Steps to Get Laggards Going
• A Data Protection Officer’s Guide to GDPR ‘Privacy by Design’
• DPO’s Guide to the GDPR Galaxy

Marc French is the senior vice president and chief trust officer at Mimecast. He has more than 25 years of technology experience in engineering, operations, product management, and security. Prior to his current role, Marc was the CSO of Endurance International Group/Constant … View Full Bio

Article source: https://www.darkreading.com/endpoint/gdpr-101-keeping-data-safe-throughout-the-supply-chain/a/d-id/1331848?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Financial institutions traditionally have established some of the most secure perimeters and defenses against cybercriminals and nation-state actors, but new studies show how they often struggle to detect or quell ongoing attacks that have infiltrated their internal networks.

CISOs from major financial firms surveyed and interviewed recently by Carbon Black say they’re seeing attackers moving across their networks under the cover of legitimate applications and tools such as Windows PowerShell (89%), Windows Management Interface (59%), and SSH (28%). Those camouflaged, memory-based attacks – aka file less attacks – were used in more than half of successful breaches of the bank networks, according to Carbon Black.

In addition to the usual Windows utility suspects, Google Drive, unsigned digital certificates, and legit processes hiding malicious code (aka process hollowing), each were found in about 10% of cases at banks.

Leigh-Anne Galloway, cybersecurity resilience lead at Positive Technologies, says these methods work for the bad guys because banks often don’t pay close attention to the security of their internal networks. Her firm, which provides penetration testing to banks in Europe and elsewhere, uses legitimate tools in those engagements. “When doing pen tests, we try to act as close as possible to the actions of the attacker – including ‘living off the land’ – so that the organization can understand how well its internal monitoring tools for attacks like SIEM or SOC work,” she says.

The pen testers run Mimikatz PowerShell version as well as the “procdump” utility, where they copy operating system memory. “You can extract passwords from this dump on your laptop, which naturally will go unnoticed by the protection systems. Such methods show high efficiency,” she days, with the pen testers able to steal passwords from the operating system memory using Mimikatz in 100% of banks they tested.

Persistent attackers aren’t backing down when banks detect them and launch their incident response processes, either. One in four bank CISOs in the Carbon Black study say their institution faced attackers fighting back when they got spotted, trying to deter defenses and the investigation into the attack.

“They are leaving wipers or destructive malware to inhibit [IR], deleting logs, and inhibiting the capacity of forensics tools,” for example, says Tom Kellermann, chief cybersecurity officer at Carbon Black. “Sometimes they are using DDoS to create smokescreens during events.”

These counter-IR activities are forcing banks to be be more proactive and aggressive as well, he says. “They need to have threat hunting teams. You can’t just rely on telemetry and alerts.”

While banks are often relying on their IR playbooks, attackers have the freedom to freelance and counter IR activities. They’re changing their malware code on the fly when it gets detected, deleting activity logs to hide their tracks, and even targeting bank security analysts and engineers to help their cause. Carbon Black found in its study that one in ten bank victims say they spotted secondary command-and-control infrastructure set up in their networks – which can make response even more difficult.

Positive Technologies’ Galloway says attackers also encrypt their data transmissions over the victim’s network, falsify time-stamps in files, and employ file compressors and anti-debugging methods that can thwart discovery of their activity and tools.

While 90% of banks in the Carbon Black survey said they had experienced a ransomware attack threat, Kellermann says another data point appears more ominous: one in ten had spotted destructive attacks that were not ransomware-related.  “I think that’s going to grow,” he says, as attack groups use destructive malware such as data-wipers to “burn the house down” on their way out for cover or to send a message.

“The real dangers to financial institutions isn’t just dealing with identity fraud and wire fraud,” Kellermann says.

Pen testers at Positive Technologies, meantime, found gaping holes in their bank client networks: 75% of banks had employees who opened links in phishing attack tests, and 25% of them provided their credentials in a phony authentication form in the test. Positive Technologies’ analysts were able to access banks’ financial applications in 58% of their engagements, and compromise ATM management workstations in 25% of the cases, according to a report published this week.

And banks weren’t savvy at catching the pen-tests, either. “The actions of pen testers were noticed by security employees in less than 10% of banks that we tested,” Galloway says.

Related Content:

• Hacking The Penetration Test
• Iran ‘the New China’ as a Pervasive Nation-State Hacking Threat
• Are DDoS Attacks Increasing or Decreasing? Depends on Whom You Ask
• 7 Non-Financial Data Types to Secure

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/endpoint/cybercriminals-battle-against-banks-incident-response/d/d-id/1331869?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Turns out that what happens in Las Vegas actually happens in at least a couple of other places as well – from a cybersecurity standpoint.

Residents of the Las Vegas, Memphis, and Charlotte metro areas are at substantially higher risk of data theft and other cybersecurity incidents compared to residents in more than four-dozen other areas in the US.

Cloud security vendor Coronet recently analyzed network connectivity and device related data in the 55 most populated areas in the country and found Wi-Fi and cellular networks — and the devices connecting to them — to be the most insecure in these three areas, the new study shows.

The risk level of a user, expressed in the form of a threat index score, was 10 on a scale of 10 in Las Vegas and 9.8 in both Memphis and Charlotte. People logging into websites or accessing cloud data in these designated market areas (DMAs) were most at risk of experiencing security incidents than anywhere else in the country.

“While in Las Vegas there was a 43% probability of users connecting to medium-risk or high-risk networks, in the least vulnerable cities the average probability was less than one percent,” says Dror Liwer, Coronet’s founder and CISO. “While in Memphis 7% of devices had no malware protection, the national average was 0.2%,” he says.

Other risky cities and areas included Houston (9.2), Providence, RI (9.0), Birmingham, AL (9.0), and Jacksonville, FL (8.9). Rounding off the list of the Top 10 most insecure locations were three market areas in Florida — West Palm Beach-Ft. Pierce (8.9), Orlando-Daytona Beach (8.5), and Tampa–St. Petersburg–Sarasota (8.3).

For purposes of the ranking, Coronet considered any region with a threat index of 6.5 or less to be at an acceptable level of risk. By that metric, the least vulnerable metro in America from a cybersecurity standpoint in Coronet’s list was the Richmond-Petersburg area in Virginia with a threat index of just 5.8.

Others in the Top 5 least vulnerable market areas were Greensboro-Winston Salem (6.2); Norfolk-Portsmouth-Newport News (6.2); Seattle-Tacoma (6.3) and St. Louis (6.3).

To arrive at the rankings, Coronet analyzed data collected from more than one million PCs, mobile devices, and tablets running its SecureCloud endpoint software. The collected data included device posture information as well as threat, attack, and vulnerability data gathered from the cellular and Wi-Fi networks to which the devices connected.

Scoring Cities

Coronet scored connectivity infrastructure based on factors like vulnerabilities and misconfigurations that were present on them as well on metrics like wrong routing and spoofing. Among the issues the company looked at were risks posed by captive portals, rogue access points, and honeypots. Devices were scored based on things like the presence or absence of active and updated anti-malware tools, active and updated firewalls, password protection, disk and storage encryption, and operating system integrity.

The company then combined and standardized the infrastructure vulnerability score with the device vulnerability score in each region to arrive at the overall Threat Index Score using a risk score range of 1 to 10,  where 10 represented the highest risk and 1 the lowest.

So why are some regions more risky than others from a security standpoint? It has a lot to do with the presence of more threat actors and activity in certain regions than others, Liwer says. “The main issue is not so much the carriers or network providers that are mostly standardized, but rather, the presence of malicious actors,” Liwer says. “While the coffee chain network is configured the same way in [most] of its locations, the fact that three of its locations in Las Vegas are under attack has impact on the probability that users will connect to a malicious node.” 

Coronet identified several factors as contributing to heightened threat activity in certain regions of the country. For instance, locations in which there are a lot of defense, financial services companies, manufacturing activity and aerospace firms — like the Tampa-St. Petersburg area and Jacksonville – generally tend to see heightened levels of threat activity.

Fast-growing metro regions and tourist destinations like the Orlando-Daytona DMA tend to be risky as well. For instance, more than 60 million people visited the Central Florida region in a 12-month period flooding the area with unsafe devices from around the world and making them a target for attackers, Coronet said.

Regions with aged or aging populations tend to attract a higher than average amount of threat activity as well. The West Palm Beach-Fort Pierce area with its large population of mostly older, wealthy and likely digitally unsophisticated residents makes for an attractive target for criminals as well.

Mixed Signals

The factors that make a region safer than others are less clear. For instance, the Seattle-Tacoma area, which ranked as the fourth safest in the Coronet report, is one of the most high tech regions in the country. But threat activity here is relatively low compared to areas with a similar high-tech profile. One reason could be because the state of Washington operates one of the most efficient cybersecurity agencies in the country. Similarly, the reason why St. Louis ranked as the fifth least vulnerable region in the country could have to do with presence of Missouri Cybersecurity Center.

Related Content:

• How Smart Cities Can Minimize the Threat of Cyberattacks
• Smart Cities’ 4 Biggest Security Challenges
• City of Atlanta Hit with Ransomware Attack
• 15 US Cities Where Cybersecurity Professionals Earn Big Bucks

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/las-vegas-most-insecure-cyber-city-in-us-st-louis-least-vulnerable/d/d-id/1331868?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple