Month: October 2018

The Dark Web is the part of the internet that is inaccessible by conventional search engines and requires special anonymizing software to access.

In colloquial terms, these are the darkest corners of the internet, where a widespan of nefarious activity takes place, as highlighted in the graphic below.

The Dark Web raises many questions, even among security professionals. Here are some answers to some of the questions that surface most frequently:

How can I check to see if my information has been stolen?

You can check to see if your email address has been compromised by using https://haveibeenpwned.com” target. If your information is present here, it is likely available on the Dark Web as well.

What are some examples of Dark Web, or The Onion Router (TOR), sites?

The Dark Web features marketplaces, forums, search engines, paste sites, social media sites, and chat rooms.

What actors use the Dark Web?

Six categories of threat actors exist on the Dark Web:

1. Nation-states that utilize Advanced Persistent Threat (APT) tactics use the Dark Web for reconnaissance and espionage purposes.
2. Cybercriminals often use marketplaces in order to achieve monetary benefit.
3. Hacktivists attempt to establish a social or political cause across all different types of platforms.
4. Terrorists seek to spread propaganda and recruitment.
5. Insiders are motivated by a variety of factors, but oftentimes leak sensitive data onto the Dark Web for reprisal against their employer or for financial gain.
6. Lastly, there are curious threat intelligence analysts who want to learn more from the Dark Web, assist in bug bounty programs, or enhance their technical skillsets.

What are some case studies of Dark Web sites?

Various data is stolen and sold on the Dark Web. Below are just a few examples:

• • Financial information: Credit and debit cards are sold across many forums and marketplaces. Stolen cards come from all countries and data breaches. Oftentimes, they are sold for as little as $1. Tax data, including W-2 forms, are also popularly sold on the Dark Web. Please see the image below of popular “carding” forum, Joker’s Stash.

• • Personal Information: Everything from names, addresses, Social Security Numbers (SSN), dates of birth, and even an associated Starbucks account, is sold on the Dark Web. When this information is compiled together and sold in a transaction, these data dumps are called “fullz” because they contain all of a person’s identifiable information.

• Health records: Although health records are harder to find, they are becoming more available by the day. This is a growing concern and a vulnerability for the future.
• Miscellaneous: Drugs are everywhere on the Dark Web – you can purchase virtually any prohibited item imaginable. Moreover, you can purchase or simply download information that can be damaging to an individual – such as stolen information from the extramarital dating website Ashley Madison. You can also purchase a hacker or exploit to carry out an attack against an organization of your choosing. The possibilities are limitless.

Anything else you would like to add about the Dark Web?

I want to note that the underground criminal community has expanded to encompass anything you can imagine – goods, hitmen, even “hacker clothes.” Most of the websites have an Amazon-type feel to them, in which buyers provide seller feedback and note the authenticity of the stolen goods/services/information. The majority of transactions are handled in cryptocurrency (usually bitcoin), mail forwards, and electronic gift cards. I don’t encourage anyone to do their Christmas shopping here, though.

About the author: Wanda Archy is a cyber threat intelligence specialist focused on Dark Web investigations. Currently, Wanda is a Supervisor in RSM’s Security, Privacy, and Risk services. She received her Master’s degree in Security Studies and Bachelor’s degree in Science, Technology, and International Affairs from Georgetown University. Wanda has her CISSP, CEH, and Security+ certifications, and speaks Russian.

[ISACA Now Blog]

This is the second post in a series, where we’ll discuss cloud service vulnerability and risk management trends in relation to the Common Vulnerability and Exposures (CVE) system. In the first blog post, we wrote about the Inclusion Rule 3 (INC3) and how it affects the counting of cloud service vulnerabilities. Here, we will delve deeper into how the exclusion of cloud service vulnerabilities impacts enterprise vulnerability and risk management.

 

Traditional vulnerability and risk management

CVE identifiers are the linchpin of traditional vulnerability management processes. Besides being an identifier for vulnerabilities, the CVE system allows different services and business processes to interoperate, making enterprise IT environments more secure. For example, a network vulnerability scanner can identify whether a vulnerability (e.g. CVE-2018-1234) is present in a deployed system by querying said system.

The queries can be conducted in many ways, such as via a banner grab, querying the system for what software is installed, or even via proof of concept exploits that have been de-weaponized. Such queries confirm the existence of the vulnerability, after which risk management and vulnerability remediation can take place.

Once the existence of the vulnerability is confirmed, enterprises must conduct risk management activities. Enterprises might first prioritize vulnerability remediation according to the criticality of the vulnerabilities. The Common Vulnerability Scoring System (CVSS) is one way on which the triaging of vulnerabilities is based. The system gives each vulnerability a score according to how critical it is, and from there enterprises can prioritize and remediate the more critical ones. Like other vulnerability information, CVSS scores are normally associated to CVE IDs.

Next, mitigating actions can be taken to remediate the vulnerabilities. This could refer to implementing patches, workarounds, or applying security controls. How the organization chooses to address the vulnerability is an exercise of risk management. They have to carefully balance their resources in relation to their risk appetite. But generally, organizations choose risk avoidance/rejection, risk acceptance, or risk mitigation.

Risk avoidance and rejection is fairly straightforward. Here, the organization doesn’t want to mitigate the vulnerability. At the same time, based on information available, the organization determines that the risk the vulnerability poses is above their risk threshold, and they stop using the vulnerable software.

Risk acceptance refers to when the organization, based on information available, determines that the risk posed is below their risk threshold and decides to accept the risk.

Lastly, in risk mitigation, the organization chooses to take mitigating actions and implement security controls that will reduce the risk. In traditional environments, such mitigating actions are possible because the organization generally owns and controls the infrastructure that provisions the IT service. For example, to mitigate a vulnerability, organizations are able to implement firewalls, intrusion detection systems, conduct system hardening activities, deactivate a service, change the configuration of a service, and many other options.

Thus, in traditional IT environments, organizations are able to take many mitigating actions because they own and control the stack. Furthermore, organizations have access to vulnerability information with which to make informed risk management decisions.

Cloud service customer challenges

Compared to traditional IT environments, the situation is markedly different for external cloud environments. The differences all stem from organizations not owning and controlling the infrastructure that provisions the cloud service, as well as not having access to vulnerability data of cloud native services.

Enterprise users don’t have ready access to cloud native vulnerabilities because there is no way to officially associate the data to cloud native vulnerabilities as CVE IDs are not generally assigned to them. Consequently, it’s difficult for enterprises to make an informed, risk-based decision regarding a vulnerable cloud service. For example, when should an enterprise customer reject the risk and stop using the service or accept the risk and continue using the service.

Furthermore, even if CVE IDs are assigned to cloud native vulnerabilities, the differences between traditional and cloud environments are so vast that vulnerability data which is normally associated to a CVE in a traditional environment is inadequate when dealing with cloud service vulnerabilities. For example, in a traditional IT environment, CVEs are linked to the version of a software. An enterprise customer can verify that a vulnerable version of a software is running by checking the software version. In cloud services, the versioning of the software (if there is one!) is usually only known to the cloud service provider and is not made public. Additionally, the enterprise user is unable to apply security controls or other mitigations to address the risk of a vulnerability.

This is not saying that CVEs and the associated vulnerability data are useless for cloud services. Instead, we should consider including vulnerability data that is useful in the context of a cloud service. In particular, cloud service vulnerability data should help enterprise cloud customers make the important risk-based decision of when to continue or stop using the service.

Thus, just as enterprise customers must trust cloud service providers with their sensitive data, they must also trust, blindly, that the cloud service providers are properly remediating the vulnerabilities in their environment in a timely manner.

The CVE gap

With the increasing global adoption and proliferation of cloud services, the exclusion of service vulnerabilities from the CVE system and the impacts of said exclusion have left a growing gap that the cloud services industry should address. This gap not only impacts enterprise vulnerability and risk management but also other key stakeholders in the cloud services industry.

In the next post, we’ll explore how other key stakeholders are affected by the shortcomings of cloud service vulnerability management.

Please let us know what you think about the INC3’s impacts on cloud service vulnerability and risk management in the comment section below, or you can also email us.

Victor Chin, Research Analyst, Cloud Security Alliance, and Kurt Seifried, Director of IT, Cloud Security Alliance

[Cloud Security Alliance Blog]