November 5, 2014 | Leave a Comment
By Avani Desai, Executive Vice President, BrightLine
On 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.
November 4, 2014 | Leave a Comment
By Kamal Shah, VP of Products and Marketing
Between 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.
October 29, 2014 | Leave a Comment
By Krishna Narayanaswamy, Chief Scientist, Netskope
We 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.
Are you enforcing cloud app policies for mobile users? Tell me here or Tweet it @Krishna_Nswamy #mobilecloudbffs
October 29, 2014 | Leave a Comment
By Kaushik Narayan, Chief Technology Officer, Skyhigh Networks
Consumers 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.
October 17, 2014 | Leave a Comment
By Sekhar Sarukkai, VP of Engineering, Skyhigh Networks
A 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. http://marc.info/?l=openssl-dev&m=141333049205629&w=2).
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.
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:
- Gartner estimates by 2017, 50% of all network attacks will use SSL.
- McAfee, shows in its 2014 first quarter threat report the use of stolen certificates to sign malware continues to increase at a rate of nearly 50% quarter over quarter since 2012.
- Kaspersky Labs this year discovered multi-year APT campaigns, like Carreto and Windigo, stealing SSL and SSH keys.
- Over 90% of externally-facing servers impacted by Heartbleed have not been fully remediated.
- IBM X-Force is still seeing over 7,000 attacks per day against its customers using the Heartbleed vulnerability.
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.
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:
- Opens the MY certificate store
- Allocates 3C245h bytes of memory
- Calculates the actual data size
- Frees the allocated memory
- Allocates memory for the actual data size
- The PFXExportCertStoreEx function writes data to the CRYPT_DATA_BLOB area to which the pPFX points
- 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.
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.
These 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.
October 10, 2014 | Leave a Comment
By Chau Mai, Senior Product Marketing Manager, Skyhigh Networks
It’s good to learn from your mistakes. It’s even better to learn from the mistakes of others. Skyhigh has some of the security world’s most seasoned data loss prevention (DLP) experts who’ve spent the last decade building DLP solutions and helping customers implement them. So, we thought we’d pick their brains, uncover some of the most common missteps they’ve seen IT make when rolling out DLP in practice, and share them so you can avoid the mistakes of IT practitioners past.
In this piece, we specifically address mistakes when rolling out DLP to protect data in the cloud. So without further ado – the 7 deadly sins of Cloud DLP:
- Lust – It’s natural to be tempted by the allure of cloud DLP. However, make sure that your cloud DLP deployment preserves the actual functionality of your cloud applications. You don’t want to break the native cloud applications’ behavior. For example, let’s say your DLP solution has detected sensitive content in Box and enforces it via encryption. Your end users should still be able to preview documents, perform searches, and overall have a seamless experience even with cloud DLP in place.
- Greed – Cloud applications can contain enormous amounts of information – in some cases, glittering terabytes of data. However, as with traditional on-premise DLP, there’s no need to try and scan everything all at once. We recommend filtering on user attributes (group, geography, employee type, etc.) as well as on sharing permissions (i.e. externally vs internally) and prioritizing high-risk documents.
- Envy – Do your employees envy others who have the ability to do their work and access cloud apps from anywhere they are? Companies are increasingly embracing the BYOD trend, and cloud DLP helps to enable that. Tame the green-eyed monster at your organization by letting cloud DLP catch all activity regardless of where the user is located, what operating system they’re using, and if they’re on-network or off-network – without the hassle of VPN.
- Gluttony – Don’t overreach and accidentally intrude on user privacy during your DLP consumption. Security teams oftentimes have access to very sensitive information, but their access should be limited to business traffic. Make sure your cloud DLP practices do not involve sniffing personal traffic (such as employees’ use of Facebook, their activity on personal banking sites, etc).
- Wrath – Avoid the wrath of employees and don’t let your cloud DLP solution negatively impact the user experience. Your employees should be able to seamlessly access and use cloud applications and enjoy the rapid responsiveness they’re accustomed to. Forward-proxies, especially when used for scanning a large amount of traffic, can cause lag and performance issues that are visible (and irritating) to the end user.
- Pride – Having strong DLP technology, processes, and people in place is something to be proud of. However, not all cloud DLP solutions are created equal. Keep your cloud DLP program running smoothly by avoiding solutions that require you to deploy agents and install certificates – an operational nightmare. And certain cloud apps, such as Dropbox and Google Drive, will detect the man-in-the-middle and refuse to work as designed.
- Sloth – This is where it pays off to be a little lazy. Let your cloud DLP provider integrate with your existing enterprise DLP solution. There’s no reason to re-work the efforts you’ve put into the people, processes, and technology. Look for a vendor that will extend your existing on-premise DLP policies to the cloud.
Cloud DLP is rapidly becoming a priority for security and compliance teams. As you evaluate solutions, be sure to keep these mistakes in mind. To learn more about common DLP missteps, check out our cheat sheet.
October 8, 2014 | Leave a Comment
By Christine Drake, Senior Product Marketing Manager, Venafi
When attending the 2014 PCI Community Meetings in Orlando in early September, the PCI SSC kicked off the conference with a presentation by Jake Marcinko, Standards Manager, on Business-as-Usual (BAU) compliance practices. The PCI DSS v3, released in November 2013, emphasizes that security controls implemented for compliance should be part of an organization’s business-as-usual security strategy, enabling organizations to maintain compliance on an ongoing basis.
Compliance is not meant to be a single point in time that is achieved annually to pass an audit. Instead, compliance is meant to be an ongoing state, ensuring sustained security within the Cardholder Data Environment (CDE). Security should be maintained as part of the normal day-to-day routines and not as a periodic compliance project.
To highlight the lack of business-as-usual security processes, Jake referenced the Verizon 2014 PCI Compliance Report, saying that almost no organization achieved compliance without requiring remediation following the assessment and there is dismally low continued compliance—only 1 out of 10 passed all 12 of the PCI DSS requirements in their 2013 assessments. But this was up from only 7.5% in 2012.
Four elements of ongoing, business-as-usual security processes were outlined:
- Monitor security control operations
- Detect and respond to security control failures
- Understand how changes in the organization affect security controls
- Conduct periodic security control assessments, and identify and respond to vulnerabilities
Jake mentioned that automated security controls help with maintaining security as a business-as-usual process, providing ongoing monitoring and alerting. If manual processes are used, they need to ensure that regular monitoring is conducted for continuous security.
The PCI DSS emphasis on business-as-usual security processes does not apply to any particular PCI DSS requirement, but instead applies across the standard. When considering how this applies to keys and certificates, manual security processes are unsustainable. A study by Ponemon Research found that, on average, there are 17,000 keys and certificates in an enterprise network, but 51% of organizations are unaware of how many certificates and keys are actively in use. Although some of these keys and certificates will not be in scope of the PCI DSS, a considerable number are used in the CDE to protect Cardholder Data (CHD).
In a recent webinar on PCI DSS v3 compliance for keys and certificates with 230 attendees, a poll revealed that over half (53%) either applied manual processes to securing their keys and certificates (41%) or did not secure them at all (12%). When specifically asked about their business-as-usual security processes for keys and certificates, more than half (53%) said they had no business-as-usual processes, but merely applied a manual process at the time of audit.
Organizations need automated security to deliver business-as-usual security processes for keys and certificates. This should include comprehensive discovery for a complete inventory of keys and certificates in scope of the PCI DSS, daily monitoring of all keys and certificates, establishment of a baseline, alerts of any anomalous activity, and automatic remediation so that errors, oversights, and attacks do not become breaches.
During his presentation, Jake noted that, for now, implementing business-as-usual security controls is a best practice according to the PCI DSS v3, and not a requirement. But he said that best practices often become requirements—so don’t wait! Start incorporating business-as-usual security practices now.
Learn how Venafi can help you automate key and certificate security required in PCI DSS v3—simplifying and ensuring repeated audit success while providing ongoing security for your CDE.
October 7, 2014 | Leave a Comment
By Scott Hogrefe, Senior Director, Netskope
Content inspection has come a long way in the past several years. Whether it is our knowledge and understanding of different file types (from video to even the most obscure) or the reduction of false positives through proximity matching, the industry has cracked a lot of the code and IT and businesses are better off as a result. One constant that has remained true, however, is the fact that you just can’t inspect content you can’t see. This probably seems like an obvious point, and for traditional solutions, we can solve for this by simply pointing the tool at repositories that might have been (for whatever reason) overlooked. But these repositories are relatively easy to discover because, frankly, it’s harder to hide content when it’s occupying storage that IT is responsible for maintaining in the first place. It’s hard to lose a NAS (though not impossible — some of us have stories we could share, no doubt). But this changes when it comes to content in the cloud. Let’s break down some of the challenges here:
- There are 153 cloud storage providers today and the average organization, according to the Netskope Cloud Report, is using 34 of them. Considering IT are typically unaware of 90% of the cloud apps running in their environment, this means that content is in 30+ cloud apps that IT has no knowledge of (and that’s just cloud storage, the average enterprise uses 508 cloud apps!).
- Once you know that an app is in use, inspection of content in the cloud has required movement of said content. Since many traditional tools perform inspection of content as it flies by, the scope of inspection is limited to when content is being uploaded or when it is downloaded. Therefore, content may exist in a cloud app for several years before it’s ever inspected.
- The “sharing” activity so popular in cloud apps today is done by sending links rather than the traditional “attachment” method. Since the link doesn’t contain the file, the inspection is useless.
For the first of our challenges above, vendors like Netskope can quickly discover all apps running in your enterprise and tell you whether the usage of these apps is risky or not.
For challenges two and three, Netskope just introduced Netskope Active Introspection, which enables customers to examine, take action or enforce policies over all content stored in a cloud app. This means that regardless of whether the data was placed in a cloud app yesterday or years ago, enterprise IT can take advantage of this solution’s leading real-time and activity-aware platform to protect it. In addition, Active Introspection provides data inventory and classification, understands app and usage context, creates a content usage audit trail, and can be deployed alongside Active Cloud DLP.
What’s even more killer is that Active Introspection can be run as part of your overall policy framework and can typically run through an entire repository in less than 30 minutes. So let’s say that you want to encrypt specific data – Active Introspection discovers the content, understands whether the content meets certain criteria (such as sensitive or high value content), and completes the step of encrypting it, right then and there. There are additional actions that can be triggered automatically, such as alerting the end user, changing to ownership of the content to the appropriate person, encrypting the content, and many more.
My colleague, Rajneesh Chopra, just published a Movie Line Monday that talks about how customers are using Active Introspection and inspection capabilities together. If we think of this as a spectrum, imagine that on one side you’ve got content that’s constantly being moved in and out of a cloud app – for that, we have inspection that’s happening in real-time. On the other side of the spectrum you have content that’s already in the cloud app and being shared via links – for that, we have introspection. It’s complete coverage. You should check it out here, but suffice it to say, for our customers, the availability of Active Introspection within the Netskope Active Platform means that they are now able to go more confidently into cloud apps they’ve cautiously embraced. For these customers, there’s a strong understanding that safe cloud enablement requires a comprehensive solution that can be flexible enough to cover the myriad use cases they’re confronted with.
Do you have a solid handle on the cloud apps in your organization? What about the content contained within them? We’d love to hear from you and address any questions you have or show you a demo. Reach out to us at [email protected] or @Netskope to get a conversation started.