Shared Responsibilities for Security in the Cloud, Part 1 Arrow to Content

November 24, 2014 | Leave a Comment

By Alexander Anoufriev, CISO, ThousandEyes

Introduction: Security Responsibilities in the Cloud Era

When businesses owned their applications and all underlying infrastructure, they also owned their security. Now this is changing with a shift in ownership and operational responsibilities over many applications as they are moving to the Cloud. In the cloud era, security is not owned solely by the cloud service provider (CSP) or consumer. Cloud security is a shared responsibility.

To illustrate this model of shared responsibility I will be using:

  • ThousandEyes SaaS Platform as an example of a cloud application which is owned and operated by ThousandEyes
  • Cloud Security Alliance (CSA) Trusted Cloud Initiative (TCI) reference architecture

We’ll need to understand the high level architecture of this specific solution. The ThousandEyes solution consists of three major components (see Figure 1):

  1. SaaS Platform, which is installed and operated in the ThousandEyes data center
  2. Enterprise Agent, which is installed in the customer’s network
  3. Cloud Agent, which is installed in hosting providers’ networks and managed by ThousandEyes

We monitor the performance of networks and applications inside of an enterprise, on the internet and in the cloud. As a part of our service, we process and store the following data elements:

  • User accounts (name, email)
  • Hashes of passwords (only if local authentication is in place; in Web SSO with SAML scenario this is not applicable)
  • Definitions of network performance tests
  • Results of the tests (measurements)
  • Alerts
  • Reports
  • Support tickets

Fig 1
Figure 1: ThousandEyes solution overview

Responsibilities by TCI Domain

Governance, Risk and Compliance
Figure 2 illustrates responsibility for the governance, risk and compliance (GRC) domain of TCI architecture. This domain is responsible for the identification and implementation of the appropriate organizational structures, processes, and controls to maintain effective information security governance, risk management and compliance. Both parties, the service provider (ThousandEyes in this example) and the consumer, are independently responsible for all of the listed processes.

Fig 2
Figure 2: Responsibility for Governance, Risk and Compliance

Responsibility for specific processes will differ between provider and consumer, for example: the service provider manages compliance with its internal policies, control standards and procedures, while it designs, develops, deploys and operates the service. The customers manage compliance while they use the service.

Privilege Management Infrastructure
Privilege Management Infrastructure ensures that users have the access and privileges required to execute their duties and responsibilities with Identity and Access Management (IAM) functions. Figure 3 illustrates shared responsibilities in IAM.

Fig 3
Figure 3: Responsibility for Privilege Management Infrastructure

In our example, the identity management process extends from a service provider to a service consumer while other related processes and services exist independently in both entities. With the ThousandEyes SaaS Platform, customers are able to take advantage of their own web single sign on (SSO) technologies. In this case, they become responsible for authentication, authorization, and privilege management. Alternatively, they can use ThousandEyes-supplied identity information.

Threat and Vulnerability Management
This domain provides core IT security service and processes. Figure 4 demonstrates how responsibilities are allocated between the service provider and consumer.

Fig 4
Figure 4: Responsibility for Threat and Vulnerability Management

Here we can see that some of the security processes/services are fully shifted to the service provider. All infrastructure-related compliance testing, vulnerability management and penetration testing are operated by the service provider, while threat management exists on both sides and often covers different threats. Due to this, they are two different processes.

(Part 2 of this post will run tomorrow.)

Lessons from Apple iCloud Data Leak Arrow to Content

November 19, 2014 | Leave a Comment

By Paul Skokowski, Chief Marketing Officer, Accellion

Accellion-Blog-Apple-iCloud-FINALThe theft of celebrity photos from Apple iCloud is a stark reminder of the need to think twice before storing data. For many people using a Mac the default behavior is to automatically back up and save data to iCloud. It’s wonderfully appealing and convenient and seamlessly integrates into practically everything you do on the Mac.  In fact it is so easy most people don’t think twice about what they are storing and that is where the problem begins.

When I recently updated my Macbook it felt as if I was being repeatedly nudged, reminded, coaxed, and invited to store my data in iCloud. Saying “no” to each of these invitations wasn’t easy and most people cave in quite quickly, because they think “what could be the harm?” The recent Apple iCloud scandal clearly illustrates the potential risks. While in this case the target of the iCloud theft was celebrity photos, the theft could have been similarly damaging to a business if sensitive information had been stolen and shared.

One of the biggest concerns that companies have around cloud technologies is the security of their digital content. Personal pictures are one thing, but it’s important to remember that companies manage sensitive data ranging from upcoming product plans to employee personnel files every single day, and that it all needs be secured. That’s why, instead of allowing employees to use solutions such as iCloud for work-related information, companies must take the time to map out a cloud security strategy and deploy enterprise grade solutions to share and store their business data.

The Apple iCloud scandal offers several important lessons:

  • Use Two-Factor Authentication: Two-factor authentication that requires the user to enter not only a password but also a one-time PIN sent to a trusted cell phone should be the default setting for cloud-storage services. While it is possible to set up two-factor authentication for iCloud, it was not easy or obvious how to do so.  If the victims’ accounts had been configured to require two-factor authentication, the hackers would not have been able to log in even knowing the account passwords.
  • Store With Care: While automatic backup and sync makes life easy, it is not always the best bet when you’re working with sensitive materials.  For work, this sensitive information could include personal data from employment records, financial data, customer information or product roadmap details. Ensuring that sensitive material is only being saved into secure solutions is essential for sensitive work-related information.
  • Trust Private Clouds: For the highest degree of confidence in and control over cloud storage, enterprises should deploy private-cloud solutions, so they are not at the mercy of the security practices (and security lapses) of third-party software providers.

So what do I use to securely sync and store my work information and make sure I have a backup?

I use Time Machine with an external hard drive to make sure I can easily restore all my content if my computer gets damaged or when I want to copy over all my content to a new machine.  And to help me do my work on a daily basis I use kiteworks by Accellion for syncing and sharing information across my iPad, iPhone and Macbook since it encrypts all data in transit and at rest, supports two-factor authentication, and automatically detects and stops brute-force password attacks.

So next time that pop up window invites you to store data to iCloud – remember the celeb photos scandal and think twice. By deploying kiteworks on trusted private clouds, enterprises can greatly reduce their vulnerability to sensitive information being exposed.

From BYOD to WYOD: Get Ahead of Wearable Device Security Arrow to Content

November 11, 2014 | Leave a Comment

By Paula Skokowski, Chief Marketing Officer, Accellion

Accellion-Blog-WYOD-FINALWearable technology is the new “it” thing. From FitBit, to Google Glass, to Samsung Galaxy Gear, and now the Apple iWatch, users are literally arming themselves with the latest gadgets. This is particularly true among early adopters who are counting the days until the release of the Apple iWatch.

While early adopters used to represent only a small number of technology trendsetters, a 2014 study found that of individuals aged 18 to 44, 56% say they have been the first among their friends, colleagues or family members to try a new product or service. With soon-to-be-launched devices promoted widely online and user reviews instantly pushed out to the masses via social media, anyone can step forward to be the first in line to make a purchase – including employees at your company.

This means enterprise IT teams also need to be one step ahead of the trends. While this doesn’t mean that IT needs to camp out overnight at the Apple store, it does mean that IT needs to anticipate what devices will be coming into the workplace and how to keep enterprise security intact. According to a global forecast by CCS Insight, wearable device shipments are expected to hit 22 million this year, up from 9.7 million in 2013, and will continue to grow to 135 million in 2018. The age of Wear Your Own Device (WYOD) is here, and IT needs to include these devices into their security strategies to make sure that any corporate data accessed on these devices is secure. Wearable devices are promising users easy access to applications and data on smartphones, which could eventually include enterprise information

So it’s not too early to start planning how to extend your BYOD policy beyond smartphones to WYOD. Wearable tech is considered fun and hip, but from an enterprise standpoint it needs to be taken seriously. While WYOD offers opportunities for increased mobile productivity it needs to be worked into an organization’s overall mobile security strategy.

REST IN PEACE SOC 3 SEAL Arrow to Content

November 5, 2014 | Leave a Comment

By Avani Desai, Executive Vice President, BrightLine

rest-in-peace-soc-3-sealOn October 2, 2014, the AICPA and CPA Canada announced their joint decision to discontinue the seal programs for Systrust and SOC 3 Systrust for Service Organizations.

In their announcement, the AICPA and CPA Canada stated that both of these organizations recognize that there has been growth in the attestation/assurance services market, especially in the area of systems reliability and service organization controls – and it’s with this in mind that they will continue to ensure the effectiveness of these services despite the seal program coming to an end.

This doesn’t mean that the SOC 3 examination is gone, just the seal. According to Bryan Walker, Director of Practitioner Support, CICA:

“The SOC 3 for SysTrust for Service Organizations will remain as part of the initiatives for Service Organization Controls. The SOC 3 seal program will be terminated and the SOC 3 seal will no longer be available.”

Therefore, service organizations still complete a SOC 3 examination, which provides a shorter report than a SOC 2 examination including only the auditor’s opinion, management’s assertion and the system description.

So what does that mean for service organizations that underwent a SOC 3 examination?

After December 31, 2014, only the seal that was jointly managed by the AICPA and CPA Canada will not be provided to service organizations.. Meanwhile, a seal that has already been issued under an existing license will remain active through its expiration date. Seals will still be issued through to December 31, 2014, to any SysTrust and SOC 3 engagements currently in progress – including renewals of existing SOC 3 SysTrust for Service Organization and SysTrust seals. After that date, however, anyone who continues to use SysTrust related marks must disclose to clients that the seal program is not active, and is not supported by or associated with AICPA and CPA Canada.

Also, do not fret; service organizations can still complete the SOC 2 examination, which will still provide the user entity the same level of comfort – just not freely distributed.

You should also know that CPA Canada stated in the announcement that they are reviewing the WebTrust for Certification Authorities seal program. While it currently continues, the review is to determine whether the benefits of the program justify the resources necessary for its continuation.

Clearly, there is a lot of assessment and change underway – however, every effort has been made to see that these changes will not cause a disruption within the service organization control reporting world.


The Data Factory: 12 Essential Facts on Enterprise Cloud Usage & Risk Arrow to Content

November 4, 2014 | Leave a Comment

By Kamal Shah, VP of Products and Marketing

carr blog imageBetween headlines from the latest stories on data breaches and the hottest new apps on the block, it’s easy to be captivated with what people are saying, blogging, and tweeting about the state of cloud adoption and security. But let’s face it: It’s hard to separate the hype from the truth, and stories about security can range from hyperbolic to accurately frightening.

The fifth installment of our quarterly Cloud Adoption and Risk (CAR) Report presents a data-based analysis of enterprise cloud usage. With cloud usage data from over 13 million enterprise employees and 350 organizations spanning all major verticals, the report is the industry’s most comprehensive and authoritative source of information on how employees are using cloud services. For the first time in the report’s history, we’ve partnered with the Cloud Security Alliance to gather IT managers’ perceptions on cloud adoption and risk and compare their perceptions with hard data. The results reveal a disparity between perception of enterprise cloud use and reality.

You can download the full report here. In addition to popular recurring features such as the Top 20 Enterprise Cloud Services and the Ten Fastest-Growing Applications, the latest report contains several shocking findings.

Mind the Cloud Enforcement Gap
IT often blocks cloud services that fail to meet their organization’s acceptable use policies. Due to changing cloud service URLs, inconsistent policy enforcement, and unmonitored exceptions, the cloud enforcement gap is a shocking 6x. For example, more than 50% of the enterprises intended to block Apple iCloud, but actual usage data showed iCloud was blocked in only 9% of the enterprises.

Don’t Underestimate Insider Threat
Security professionals believe insider threat incidents are rare, with only 17% of respondents aware of an incident at their organization in the past year. The reality is 85% of companies had cloud usage activity strongly indicative of insider threat.

The Cloud 1% and the 80-20 Rule
While the average organization employed 831 cloud services, the distribution of data revealed that 80% of data uploaded to the cloud goes to just 11 cloud services – less than 1% of the total number. Still, enterprises can’t ignore other cloud services: The remaining 20% of data account for 81.3% of anomalous activity indicative of malware, compromised account, and insider threat.

IT’s Worst Nightmare: The World’s Riskiest User
One anonymous user uploaded more than 15 GB of data to high-risk services such as Sourceforge and ZippyShare over 3 months. This individual used 182 high-risk cloud services, any one of which could have been a vector for confidential data to be inappropriately leaked or for malware to be introduced into the enterprise, thus proving that even a single employee is capable of significant damage to corporate security.

The Data Factory: 12 Essential Factors on Enterprise Cloud Usage and Risk from Skyhigh Networks Cloud Security Software

Mobile and Cloud: BFFs 4Ever Arrow to Content

October 29, 2014 | Leave a Comment

By Krishna Narayanaswamy, Chief Scientist, Netskope

Netskope Cloud Report - October 2014We released the Netskope Cloud Report for October today. In it, we analyze the aggregated, anonymized data collected from tens of billions of events across millions of users in the Netskope Active Platform, and highlight key findings about cloud app usage in enterprise as seen in the Netskope Active Platform. This includes our count of enterprise cloud apps (579) and percent that are enterprise-ready (88.7 percent), as well as top apps, activities, and policy violations. But what was really interesting about this quarter’s findings is the level of cloud app activity occurring on mobile devices.

As we all know, mobile is the perfect medium for information “snacking.” When it comes to enterprise cloud apps, they also happen to be perfect for bite-sized work. In a world where the workday never seems to end, every minute is a zero-sum-game. So, whether it’s a quick approval of an expense report, a quickly dashed-off email, or a “while I’m thinking of it” document share from cloud storage, nearly half of all activities occur on mobile devices. Some of the most common are send (57 percent), approve (53 percent), view (48 percent), login (47 percent), and post (45 percent).

With all of those activities, mobile is also a place for an increasing number of policy violations. We define a policy violation as when a user attempts an activity on which an administrator has set a policy in the Netskope Active Platform (such as “Don’t share content from cloud storage outside of the company”). We found that 59 percent of all policy violations involving download, and more than one-third of policy violations involving a DLP profile (such as PII, PCI, PHI, Confidential, etc.), occur on mobile devices. Our researchers believe that the high rate of download policy violations on mobile devices could be due to administrators both setting “no download” policies as well as “no download to mobile” policies (the latter because that is a source of concern for data leakage, especially in the case of BYOD), both of which would be triggered on a mobile device.

See the Netskope Cloud Report infographic here and get the full report here.

Are you enforcing cloud app policies for mobile users? Tell me here or Tweet it @Krishna_Nswamy #mobilecloudbffs



In Plain Sight: How Hackers Exfiltrate Corporate Data Using Video Arrow to Content

October 29, 2014 | Leave a Comment

By Kaushik Narayan, Chief Technology Officer, Skyhigh Networks

data-exfiltration-blog-imageConsumers and companies are embracing cloud services because they offer capabilities simply not available with traditional software. Cyber criminals are also beginning to use the cloud because it offers scalability and speed for delivering malware, such as in the recent case of Dyre, which used file sharing services to infect users. The latest evolution of this trend is attackers using the cloud to overcome a key technical challenge – extracting data from a company. Under the cover of popular consumer cloud services, attackers are withdrawing data from the largest companies in ways that even sophisticated intrusion prevention systems cannot detect.

Previously, researchers at Skyhigh uncovered malware using Twitter to exfiltrate data 140 characters at a time. Skyhigh recently identified a new type of attack that packages data into videos hosted on popular video sharing sites, a technique difficult to distinguish from normal user activity.

The Industrialization of Hacking
The target of these attacks ranges from customer data such as credit card numbers and social security numbers to intellectual property, which can include design diagrams and source code. In recent years, hacking has undergone a revolution. Once a hobbyist pursuit, hacking is now performed at industrial-scale with well-funded teams backed by cartels and national governments. Stealing data is big business, whether to compromise payment credentials and resell them for profit or to gain access to intellectual property that could allow a competitor to catch up on years (or decades) of research and development.

In response, companies have made significant investments in software that can detect telltale signals that attackers have gained access to their network and are attempting to extract sensitive data. With these intrusion prevention systems in place, it can be quite challenging for attackers to remove a large amount of data without being discovered. In the same way that thieves would find it difficult to sneak bags of money out the front door of a bank undetected by guards and security cameras, today’s cyber criminals need a way to mask their exit. That’s why they’ve turned to cloud services to make large data transfers.

Their latest technique involves consumer video sites. There are two attributes that make video sites an excellent way to steal data. First, they’re widely allowed by companies and used by employees. There are many legitimate uses of these sites such as employee training videos, product demos, and marketing the company’s products and services. Second, videos are large files. When attackers need to extract large volumes of data, video file formats offer a way to mask data without arousing suspicions about a transfer outside the company.

How the Attack Works
Once attackers gain access to sensitive data in the company, they split the data into compressed files of identical sizes, similar to how the RAR archive format transforms a single large archive into several smaller segments. Next, they encrypt this data and wrap each compressed file with a video file. In doing so, they make the original data unreadable and further obscure it by hiding it inside a file format that typically has large file sizes. This technique is sophisticated; the video files containing stolen data will play normally.

They upload the videos containing stolen data to a consumer video sharing site. While they’re large files, it’s not unusual for users to upload video files to these types of sites. If anyone checked, the videos would play normally on the site as well.

After the videos are on the site, the attacker downloads the videos and performs the reverse operation, unpacking the data from the videos and reassembling it to arrive at the original dataset containing whatever sensitive data they sought to steal.



What Companies Can Do to Protect Themselves
Traditional intrusion detection technology generally does not detect data exfiltration using this technique. One way to identify this attack is an anomalous upload of several video files with identical file sizes. To identify this type of activity, what is needed is a big data approach to analyzing the routine usage of cloud services in the enterprise to detect these anomalous events.

Skyhigh analyzes all cloud activity to develop behavioral baselines using time series analysis and machine learning, and identified the attack in the wild at a customer site. Importantly, the detection relied on analysis of normal usage activity rather than detecting malware signatures that don’t exist before the attack has been catalogued. Skyhigh’s approach requires no knowledge of the attack before it’s detected.

Companies can proactively take steps to protect themselves by limiting uploads to video sharing sites while allowing the viewing or download of videos. Deploying a cloud-aware anomaly detection solution can also give early warning to an attack in progress and either block it from occurring or quickly allow a company to take action to stop the attack and prevent additional data from being exfiltrated.

The volume and sophistication of attacks is increasing. In this threat environment, companies must take additional steps to protect data while allowing the use of cloud services that also drive innovation and growth in their businesses. State-sponsored attacks and sophisticated criminal organizations are now using the cloud as a delivery vehicle for malware and as an exfiltration vector, but companies can also take advantage of a new generation of cloud-based detection and protection services to safeguard their data and protect themselves. Download our cheat sheet to learn other actionable steps for reducing risk to data in the cloud.


Poodle – How Bad Is Its Bite? (Here’s the Data) Arrow to Content

October 17, 2014 | Leave a Comment

By Sekhar Sarukkai, VP of Engineering, Skyhigh Networks

Poodle PicA major vulnerability affecting the security of cloud services dubbed POODLE (Padding Oracle on Downgraded Legacy Encryption) was reported on October 14th by three Google security researchers—Bodo Moller, Thai Duong, and Krzysztof Kotowicz. Their paper about the vulnerability is available here.

What is POODLE?
POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password.

This vulnerability allows for the hijacking and decryption of SSL version 3.0 connections, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. While usage of SSL 3.0 is generally limited, there is still prevalent backward-compatibility support of the protocol that exposes nearly all browsers and users.

The SSLv3 protocol has been in use since its publication in 1996. TLSv1 was introduced in 1999 to address weaknesses in SSLv3, notably introducing protections against CBC (Cipher block chaining) attacks. Although SSLv3 is considered a legacy protocol, it is still commonly permitted for backward compatibility by the default configurations of many web servers including Apache HTTP Server and Nginx. Many browsers’ support will fall back to the use of SSLv3 if an HTTPS connection to a server doesn’t support the TLSv1 protocol or a TLSv1 protocol negotiation fails for any reason.

What’s the risk?
The danger arising from the POODLE attack is that a malicious actor with control of an HTTPS server or some part of the intervening network can cause an HTTPS connection to downgrade to the SSLv3 protocol. An attack against SSLv3’s CBC encryption schemes can then be used to begin decrypting the contents of the session. Essentially, POODLE could allow an attacker to hijack and decrypt the session cookie that identifies a cloud service user to a service like Twitter or Google, and then take over your accounts without needing your password.

How to protect your company’s data
We recommend disabling the SSLv3 protocol on all servers, relying only on TLSv1.0 or greater. Additionally, company browsers and forward proxies should disallow SSLv3 and likewise permit only TLSv1.0 or greater as a minimum SSL protocol version. Enterprises should also disable the use of CBC-mode ciphers. To patch retrying of failed connections, apply TLS_FALLBACK_SCSV option (e.g.

Legacy applications relying solely on SSLv3 should be considered at-risk and vulnerable. Generic encryption wrapper software like Stunnel can be used as a workaround to provide encrypted TLSv1 tunnels.

How many cloud services are vulnerable?
As of this morning, 61% of cloud services had not addressed the Poodle vulnerability with a fix. The fact that many cloud services still support SSLv3 is a sign that cloud providers are not paying attention to what protocols are offered by their SSL stack. Cloud service providers should start looking at their SSL stack configuration and make sure they have disabled previous versions of SSLv3. In the process, they should also ensure the SSL stack’s proper use of ciphers.

We are working with customers to proactively identify vulnerable services and users and provide guidance for measures required to protect their data and user accounts. To learn more about our recommendations for securing corporate data in the cloud, download our cheat sheet.


Malicious Security—Can You Trust Your Security Technology? Arrow to Content

October 16, 2014 | Leave a Comment

By Gavin Hill, Director, Product Marketing And Threat Intelligence, Venafi

Encryption and cryptography have long been thought of as the exemplars of Internet security. Unfortunately, this is not the case anymore. Encryption keys and digital certificates have become the weakest link in most organizations’ security strategies, resulting in diminished effectiveness of other security investments like NGFW, IDS/IPS, WAF, AV, etc.

In my previous post, I discussed the difference between key management and key security. The problem today is not that encryption and cryptography are broken, but rather that there are mediocre implementations to secure and protect keys and certificates from theft. Worse yet, most organizations cannot even tell the difference between rogue and legitimate usage of keys and certificates on their networks or stop attackers from using them. Bad actors and nation states continue to abuse the trust that most have in encryption, but very few in the security industry are actually doing something about it.

Undermining Your Critical Security Controls
The threatscape has changed:

Even with all the advances in security technology over the last decade, cybercriminals are still very successful at stealing your data. The challenge is that security technologies are still designed to trust encryption. When threats use encryption, they securely bypass other security controls and hide their actions. Let’s review an example of how a bad actor can use keys and certificates to subvert any security technology or control.

Using Keys and Certificates throughout the Attack Chain
The use of keys and certificates in APT campaigns is cyclical. A typical trust-based attack can be broken up into four primary steps that include the theft of the key, use of the key, exfiltration of data, and expansion of its foothold on the network.

keys and certificates used throughout the attack chain

Step 1: Steal the Private Key
When Symantec analyzed sample malware designed to steal private keys from certificate stores, the same behavior was noted for every malware variant that was studied. In this current example, the CertOpenSystemStoreA function is used to open stored certificates, and the PFXExportCertStoreEx function exports the following certificate stores:

  • MY: A certificate store that holds certificates with the associated private keys
  • CA: Certificate authority certificates
  • ROOT: Root certificates
  • SPC: Software Publisher Certificates

The malware samples were able to steal the digital certificate and corresponding private key by performing the following actions:

  1. Opens the MY certificate store
  2. Allocates 3C245h bytes of memory
  3. Calculates the actual data size
  4. Frees the allocated memory
  5. Allocates memory for the actual data size
  6. The PFXExportCertStoreEx function writes data to the CRYPT_DATA_BLOB area to which the pPFX points
  7. Writes data (No decryption routine is required when it writes the content of the certificate store)

Step 2: Use the Key
With access to the private key, there are a multitude of use cases for a malicious campaign. Let’s review how cybercriminals impersonate a website and sign malware with a code-signing certificate.

Website impersonation can easily be achieved using the stolen private key as part of a spear-phishing campaign. The attacker sets up a clone version of the target website—Outlook Web Access (OWA) or a company portal would be a prime target. By using the stolen private key and certificate anyone that visits the website would not see any errors in the browser. The fake website also hosts the malware that is intended for the victim.

Step 3: Exfiltrate the Data
Now that the fake website is prepped and ready to go, it’s time to execute the spear-phishing campaign. Using popular social networks like LinkedIn, it is a simple process to profile a victim and formulate a well-crafted email that will entice the victim to click on a malicious link. Imagine you get an email from the IT administrator stating that your password will be expiring shortly, and that you need to change your password by logging into OWA. The IT administrator very kindly also provided you with a link to OWA in the email for you to click on and reset your password.

When you click on the link and input your credentials into the OWA website, not only are your credentials stolen, but malware is installed onto your machine. It’s important to note that the malware is also signed using a stolen code-signing certificate to avoid detection. By signing the malware with a legitimate code-signing certificate the attackers increase their chances of avoiding detection.

In part 2 of this blog series, I will cover step 4 and discuss some examples of the actions trust-based threats perform and how bad actors use keys and certificates to maintain their foothold in the enterprise network. I will also offer some guidance on how to mitigate trust-based attacks.

Register for a customized vulnerability report to better understand your organizations SSL vulnerabilities that cybercriminals use to undermine the security controls deployed in your enterprise network.

Trust Is a Necessity, Not a Luxury Arrow to Content

October 13, 2014 | Leave a Comment

By Tammy Moskites, Chief Information Security Officer, Venafi

Mapping Certificate and Key Security to Critical Security Controls
I travel all over the world to meet with CIOs and CISOs and discuss their top-of-mind concerns. Our discussions inevitably return to the unrelenting barrage of trust-based attacks. Vulnerabilities like Heartbleed and successfully executed trust-based attacks have demonstrated just how devastating these attacks can be: if an organization’s web servers, cloud systems, and network systems cannot be trusted, that organization cannot run its business.

Given the current threat landscape, securing an organization’s infrastructure can seem a bit daunting, but CISOs aren’t alone in their efforts to protect their critical systems. Critical controls are designed to help organizations mitigate risks to their most important systems and confidential data. For example, the SANS 20 Critical Security Controls provides a comprehensive framework of security controls for protecting systems and data against cyber threats. These controls are based on the recommendations of experts worldwide—from both private industries and government agencies.

sans_20_critical_security_controls_619x330These experts have realized what I’ve maintained for years—just how critical an organization’s keys and certificates are to its security posture. What can be more critical than the foundation of trust for all critical systems? As a result, the SANS 20 Critical Security Controls have been updated to include measures for protecting keys and certificates. Organizations need to go through their internal controls and processes—like I’ve done as a CISO—and ensure that their processes for handling keys and certificates map to recommended security controls.

For example, most organizations know that best practices include implementing Secure Socket Layer (SSL) and Secure Shell (SSH), but they may not realize that they must go beyond simply using these security protocols to using them correctly. Otherwise, they have no protection against attacks that exploit misconfigured, mismanaged, or unprotected keys. SANS Control 12 points out two such common attacks for exploiting administrative privileges: the first attack dupes the administrative user into opening a malicious email attachment, but the second attack is arguably more insidious, allowing attackers to guess or crack passwords and then elevate their privileges—Edward Snowden used this type of attack to gain access to information he was not authorized to access.

SANS Control 17, which focuses on data protection, emphasizes the importance of securing keys and certificates using “proven processes” defined in standards such as the National Institute of Standards and Technology (NIST) SP 800-57. NIST 800-57 outlines best practices for managing and securing cryptographic keys and certificates from the initial certificate request to revocation or deletion of the certificate. SANS Control 17 suggests several ways to get the most benefit from these NIST best practices. I’m going to highlight just a couple:

  • Only allow approved Certificate Authorities (CAs) to issue certificates within the enterprise (CSC 17-10)
  • Perform an annual review of algorithms and key lengths in use for protection of sensitive data (CSC 17-11)

Think for a moment about how you would begin mapping your processes to these two recommendations:

  • Do you have policies that specify which CAs are approved?
  • Do you have an auditable process that validates that administrators must submit certificate requests to approved CAs?
  • Do you have a timely process for replacing certificates signed by non-approved CAs with approved certificates?
  • Do you have an inventory of all certificates in your environment, their issuing CAs, and their private key algorithms?
  • Do you have an inventory of all SSH keys in your environment, their key algorithms, and key lengths?
  • Do you have a system for validating that all certificates and SSH keys actually in use in your environment are listed in this inventory?

I LOVE that I can say that Venafi solutions allow you to answer “yes” to all of these.

If you are interested in more details about mapping your processes for securing keys and certificates to the SANS Critical Security Controls, stay tuned: my white paper on that subject, coauthored with George Muldoon, will be coming soon.

Page Dividing Line