In Europe, Cloud Is the New Default

By Salim Hafid, Senior Product Marketing Manager, Bitglass

Raiders of EMEA Cloud AdoptionIf you keep up with the blog, you’ll remember our 2018 global cloud adoption report, wherein thousands of organizations deployed cloud apps since we last conducted our automated analysis of over 100,000 firms. Many in EMEA wanted to know how Europe stacked up against the rest of the world, against the US, and whether companies in region were securing their cloud environments.

EMEA leading the cloud charge

Europe has always been ahead of the curve with respect to cloud usage. Cost and compliance concerns have driven IT in every organization to migrate and enable employee mobility. Of note, the research team’s analysis found that the rate of cloud adoption in EMEA outpaced US and global adoption, topping 84 percent this year and led by major SaaS productivity apps like Office 365 – used in 65 percent of firms in EMEA today.

Microsoft’s continued investment in their SaaS suite has pushed Office 365 deployments into far more organizations than Google with G Suite. More than three times as many organizations in EMEA now use Office 365 than use G Suite.

Many companies in Europe still haven’t secured data in the cloud

A majority of organizations in EMEA still don’t have single sign-on in place. Only 47 percent of organizations in our sample had some SSO tool. What’s more, few have taken steps to secure the growing number of Shadow IT applications in use. In almost every EMEA-based organization in our sample, the Bitglass team found more than one cloud app deployed. Most companies have some productivity app in use, a cloud messaging platform, an enterprise file sync and share tool, and IaaS workloads in AWS or Azure.

Our data revealed that a majority of organizations have deployed Office 365 or G Suite in addition to Slack. In the technology sector, for example, 3 in 4 organizations have tried Slack and nearly all have some cloud productivity app deployed.

Check out our full report, we explore the underlying trends driving organizations to the cloud and compare the growth of cloud in Europe to the rest of the world.

Office 365 Security: It Takes Two to Tango

Many cloud apps – including Office 365 – operate under a shared responsibility model. Here’s what that means for your company

By Beth Stackpole, Feature Writer, Symantec

cloud Security concerns, once a long-standing hurdle to cloud deployment, may be on the wane, but the issue is still very much alive when it comes to cloud-based applications such as Microsoft Office 365.

It’s not that Office 365 is inherently less secure than other SaaS offering; it’s that companies still harbor misperceptions related to the shared responsibility model now commonplace for many cloud applications, including Microsoft Office 365. The issue is particularly acute given the rising popularity of the Microsoft cloud platform. Global cloud adoption has topped 81 percent, while Office 365 usage has surged from 34.3 percent to 56.3 percent this last year, eclipsing Google’s G suite, which held steady at 25 percent.

Under the shared responsibility model, security of physical assets, host infrastructure, network controls, and application-level controls are squarely in the hands of cloud service providers (CSPs) like Microsoft, but that hardly covers all the bases. Identity and access management and client and end point protection remain a split responsibility between the CSP and the customer; more importantly, the enterprise needs to take the reins when it comes to data security and classification—a delineation that is often lost on customers expecting that a SaaS solution means security requirements are taken care of.

“One of the most common misperceptions is that Microsoft, by default, is protecting all the data and that’s simply not the case,” says Swapnil Deshmukh, senior director of information security at Visa. “Organizations need to figure out how to protect the application stack and any code that resides there as well as how to protect data stored on the cloud itself.”

Not surprisingly, there have already been some well-publicized breaches. A wave of phishing attacks aimed at stealing passwords used Microsoft 365 Office files posing as tax forms, affecting millions of users. And then there was last year’s mishap when the Office 365 Admin Center itself inadvertently revealed usage data belonging to other tenants, which highlighted the risks in the context of regulations like the European GDPR (General Data Protection Regulations).

A holistic security approach

Symantec’s 2018 Shadow Data Report, which covers the key challenges encountered when trying to secure data and maintain compliance in cloud apps and services, reveals just how high the stakes have become. The report found that 32 percent of emails and attachments in the cloud are broadly shared and 1 percent of those contain compliance-related data, including Personally Identifiable Information (PII), Payment Card Information (PCI), and Protected Health Information (PHI), revealing a much higher risk than anticipated.

Moreover, 68 percent of organizations have some employees who exhibit high-risk behavior in cloud accounts, encompassing everything from data destruction to data exfiltration and accounts takeovers. It gets worse: The 2017 Symantec Internet Security Threat Report (ISTR) found that in 2016 one out of every 131 emails contained a malware attack, and 61 percent of organizations were hit by ransomware incidents.

Microsoft Office 365 delivers an array of security controls, including encryption of data both at rest and via network transmission, threat management and security monitoring capabilities, and online protection to ward against spam and malware. Azure Active Directory is used for authentication, identity management, and access controls and there is support for multi-factor authentication. The platform also has a built-in feature for email encryption, but it isn’t part of the default settings.

This highlights a problem for many users who simply don’t know what’s available beyond Office 365’s default security controls, notes Payton Moyer, president and COO of MLS Technology Group, a managed IT services provider. “Office 365 offers baseline security features baked in and ready to go by default, but to get the maximum security, you have to make an effort to add capabilities and turn them on,” he says.

What’s really important, experts say, is for enterprises to layer on additional security capabilities, including digital rights management; Data Loss Prevention services; as well as threat analytics, blocking, and remediation.

Adds Symantec Senior Technical Sales Manager, Adrian Covich: “People are looking for the base functionality and don’t necessarily proceed with security in mind. They also misunderstand the point to which Microsoft will secure them out of the box versus what they still need to do. There are still fundamental questions you need to answer with SaaS when it comes to the delineation of responsibilities and who has access to data. Are your users who they say they are? What data are you storing and are your business processes sufficiently secure?”

These extra protections should work holistically across the entire enterprise domain, not just for the Microsoft Office 365 cloud silo. To this point, a Cloud Access Security Broker (CASB) can integrate Office 365 and other cloud apps into the broader enterprise security architecture, delivering visibility into shadow IT and cloud application usage, providing data governance and controls for data stored in cloud apps, and leveraging machine learning and user behavior analytics to deliver advanced security and data protection.

“A CASB sits between the enterprise end user and Microsoft Office 365, looks at all the data, and allocates the right controls to it,” says Visa’s Deshmukh. “It stops data exfiltration avenues from an internal perspective and identifies adversaries that may have compromised end users.”

By sharing responsibility and taking a holistic approach, enterprises can close security gaps, minimize potential risks, and ensure a stress-free path to the cloud.

This post was originally published on Sept. 24, 2018, on Symantec.com.

Guideline on Effectively Managing Security Service in the Cloud

By Dr. Kai Chen, Director of Cybersecurity Technology, Huawei Technologies Co. Ltd.

cover of report on effectively managing cloud service securityThe cloud computing market is growing ever so rapidly. Affordable, efficient, and scalable, cloud computing remains the best solution for most businesses, and it is heartening to see the number of customers deploying cloud services continue to grow.

From the beginning of cloud’s existence, cloud service security has been among the top concerns of deployment. In order to deal with this, various organizations have invested huge efforts on cloud service security standards and researching best practices development and enforcement. Thanks to the efforts of cloud service providers (CSPs), cloud service security has reached an acceptable level. But from the cloud customers’ perspective, it is still somewhat lacking in best practices on how to secure their cloud services. The availability of such guidelines can be especially helpful for small and medium enterprises (SMEs) that constantly face shortages of professional security manpower. With this in mind, the Cloud Security Services Management (CSSM) Working Group developed the “Guideline on Effectively Managing Security Service in the Cloud” that applies to various cloud deployment models, from private, public, hybrid to community cloud.

The shared security responsibility model is no stranger to the cloud security community. Every leading CSP has published whitepapers or statements on shared security responsibility, explaining their roles and responsibilities in cloud provisioning. In other words, there are certain security responsibilities that are left to the cloud customers and are written down in cloud service agreements. The complexity is that in reality, given the same concept of shared responsibility, there are different interpretations and implementations among different CSPs. In many cases, it is challenging for cloud customers to clearly understand and bear their responsibilities in practice.

Cloud service security: A how-to

The Guideline provides an easy-to-understand guidance to cloud customers on how to design, deploy, and operate a secure cloud service with respect to different cloud service models, namely IaaS, PaaS, and SaaS, helping them ensure the secure running of service systems. With a distinct separation of responsibilities, cloud customers can clearly understand security responsibilities of their own and of CSPs, what security assurance features should be provided to bear these security responsibilities, existing gaps, and how to develop related capabilities to address such gaps.

Additionally, the Guideline provides guidance for CSPs in building cloud platform security assurance systems which can also be used by cloud service security integrators.

Not forgetting third-party security service providers that play important roles in securing cloud services, although according to the shared security responsibility model, they will have no responsibilities in cloud, these providers can leverage on the Guideline to better fit their services to CSPs and/or cloud customers.

The CSSM WG hopes that this effort allows for better understanding of cloud security responsibilities from both customers and CSPs, and through this create a more immaculate cloud security ecosystem.

Download the Guideline on Effectively Managing Security Service in the Cloud now.

How Can the Financial Industry Innovate Faster?

By Peter HJ van Eijk, Head Coach and Cloud Architect, ClubCloudComputing.com

financial services stock chart

How can the financial industry innovate faster? Why do non-technical people need to have a basic understanding of cloud technology?

Imagine this scenario. Davinci is a company providing a SaaS solution to banks to process loans and mortgage applications. Davinci runs its own software on an AWS platform, and a significant number of large mortgage providers depend on the service. As you can imagine, the loan approval process involves a lot of personal and financial data, which naturally presents a tremendous privacy risk. This raises the question of who is going to take care of these and other risks.

Cloud security: Who does what?

Cloud distributes responsibility for IT services across an IT supply chain. This supply chain is composed of independent providers, which implies that companies have technical boundaries that are matched by organizational and contractual boundaries. The concept of having technical boundaries is new—this issue didn’t exist before the digital revolution.

In our example, there is both an organizational and a technical boundary between the mortgage providers and the SaaS provider. So the question is, what happens on either side?

Amazon Web Services calls this the shared responsibility model for cloud security. I would simplify that as: What do I do, and what do you do? For example, who is responsible for patching the Operating System in an IaaS service model? Who is responsible for protecting customer data in a SaaS model? The answer will vary from company to company, technology to technology, and even from threat to threat.

Allocation of shared responsibility

Legal contracts must address the allocation of responsibilities, otherwise they are not enforceable. But, who is going to check those contracts? Who needs to make sure the contracts actually specify those tasks and lays out who is responsible for doing them and how to monitor and enforce them? Typically, this is a job for procurement and legal.

Because of this, people (in this case: procurement and legal) need to have a solid understanding not only of the given service, but also of which (technical) tasks are not part of that service.

A baseline understanding of cloud responsibilities is critical. Insufficient understanding delays the entire assessment process and reduces its quality. As one of my legal course students once said:

When I go into a conversation with a cloud provider I have time for, let’s say, 10 questions. If all these questions go to understanding basic cloud terminology and technology, I have missed the opportunity to talk about the real risk and opportunity for our company.

My takeaway from this is the following: Educate your lawyers, procurement and so on. Help them understand the cloud well enough to ask educated questions. Help them know where technical boundaries need to be translated into legal controls. Help them understand the technical and organizational shared responsibility model.

When adopting cloud (and thereby sharing responsibility with providers) make sure that everyone involved in the decision-making, implementation and enforcement has a basic understanding of:

  • cloud services and service models;
  • how these services map to technical infrastructure and software; and
  • how each of these can be located in different places and be under the control of different organizations.

Adopt faster

Better understanding of the shared responsibility model leads to faster cloud adoption because it reduces fruitless back and forth on ‘who does what.’

There are several ways to better understand the shared responsibility model. But in my opinion, the best way to gain deeper understanding, speed up dialogue, and accelerate profitable and secure cloud adoption is to study a vendor-neutral body of knowledge such as that demonstrated by CSA’s Certificate of Cloud Security Knowledge (CCSK). The CCSK tests for a broad foundation of knowledge about cloud security, with topics ranging from architecture, governance, compliance, operations, encryption, virtualization and much more, and elaborates on understanding cloud models, risks and appropriate controls, as well as the Cloud Controls Matrix, which is a very effective tool in cloud provider evaluation.

Interested in learning more about drivers and barriers to cloud adoption in the financial industry? Here a few posts and articles to get you started.

Peter van Eijk is one of the world’s most experienced cloud trainers. He has worked for 30+ years in research, with IT service providers and in IT consulting (University of Twente, AT&T Bell Labs, EDS, EUNet, Deloitte). In more than 100 training sessions, he has helped organizations align on security and speed up their cloud adoption. He is an authorized CSA CCSK and (ISC)2 CCSP trainer, and has written or contributed to several cloud training courses.

CCSK in the Wild: Survey of 2018 Certificate Holders

CCSK examEven as more organizations migrate to the cloud, there’s still a concern as to how well those cloud services are being secured. According to an article by Forbes66% of IT professionals say security is their greatest concern in adopting a cloud computing strategy.”

As you embark on your quest to fill this skills gap, you may benefit from learning how other professionals have used certificates to expand and validate their cloud knowledge. In this blog we are going to explore how Certificate of Cloud Security Knowledge (CCSK) is being used in the wild. As the first step into this exploration we surveyed current holders to ask them how their certificate impacted their job, career and overall professional development. A summary of findings from the survey, job board postings and testimonials is shared below.

Topics we’ll discuss in this blog:

  • Survey Findings
  • CCSK in Job Postings
  • Overview of Testimonials

Survey Findings

Of the individuals who had successfully passed the exam, over 40 percent reported that the CCSK helped directly progress their career- either via a salary increase, promotion, or new job/role.

Graph showing How has your career progressed since earning your CCSK

In some cases CCSK holders were given new responsibilities and moved from a more generic security role into a cloud-focused position. Specialization is a key, whether it be through a certification or other learning program. Mike Rosa, Sr. Director Public Sector Security at Salesforce affirmed this saying, “The CCSK sets me apart as an expert in Cloud Security, not a security generalist. The world is moving to cloud, and my resume should reflect this change.

Another common way the certificate helped was building credibility with clients, and helping individuals work within more specialized roles. Since it offered proof of knowledge and established trust, respondents reported being able to better serve their clients’ needs.

One of the more tangible benefits of a certificate is the possibility of a salary increase. Taking a look at those who reported a salary increase, we saw that 15.61 percent saw an increase between 8 percent to 10 percent. Below you can see the distribution of individuals who received an increase in salary of some kind.

Graph showing salary increase since earning CCSK

Types of Jobs

What types of jobs do a CCSK holders have? We found that 22 percent of the people who received a promotion were promoted into a managerial, VP/Director, or Executive role. Titles varied, but the graphic below lists the top keywords listed in respondent’s job titles.

job titles available to CCSK holders

Complementary Certifications

What types of complementary certificates did they hold or pursue? Of the people who took our survey, 52.46 percent also have their CISSP. Certificates and certifications focus on a select area of knowledge, and earning complementary certificates can be valuable. Below are some of the other certifications commonly held.

graph showing which certifications respondents hold

The flipside of this question also yielded interesting results. When asked which other certifications people intend to pursue we received mixed results. The percent interested in earning their CCSP was over 30 percent compared to the 15 percent who already held their CCSP when they took the exam.

Graph asking which certifications people will pursue

As you may already be aware, one year of experience for the CCSP is covered by earning your CCSK since the two certificates complements each other. Whereas the CCSK is more tactical, the CCSP has more of a strategic focus. You’re free to draw your own conclusions, but if you’re interested in learning more about the differences between the two, you can read CCSK vs CCSP: An Unbiased Comparison.

Job Board Searches

A question we often get is whether or not employers are looking for the CCSK and how frequently it shows up in job boards. For job postings, HPE recently conducted a search of posts listing cloud certifications as a credential. They conducted the search for the CCSS, CCSP, PCSM and several other cloud certifications on the market. Below is a summary the results they gleaned for the CCSK.

February 2018 Job Search

Certificate SimplyHired Indeed LinkedIn LinkUp Total
CCSK 180 224 145 132 681

These results vary depending on location and time of year, however, it gives a good estimate of what to expect. In an informal search during October, we discovered the following results for the United States.

October 2018 Job Search

Certificate SimplyHired Indeed LinkedIn LinkUp Total
CCSK 89 321 231 258 899

The amount of postings went up, but the actual number of listings varies throughout the year. As with all things, it is best to do your own research before determining if the CCSK is right for you. Job titles listed included: Network Security Engineer, Security Consultant,  Information Security Cloud Governance Engineer, Cloud Security Architect and Sr. Security Engineer, to name a few.

Overview of Testimonials

Last but not least we collected written feedback on how earning the cloud certificate specifically helped in people’s jobs or career. To make it easier we grouped the responses into the following categories.

Survey Testimonials Revealed

  • How their career progressed
  • How CCSK helped build credibility with clients
  • What makes the CCSK unique from other certificates.
  • How it helped them on the job
  • Benefits of a vendor-neutral certificate

In following blog posts we will be exploring some of these topics more in-depth. For now we’ve listed snippets from testimonials we received that give you an idea of what people said.

How has the CCSK helped progress your career?

Answers to How as CCSK helped progress your career

Whether or not you opt for a cloud certification there are plenty of ways to learn more about cloud security. A couple of free resources that CSA has available for you to use include: CloudBytes webinars, research artifacts and the CCSK Prep-Kit.

Interested in going deeper? Learn how to earn your Certificate in Cloud Security Knowledge by visiting our website.

CVE and Cloud Services, Part 2: Impacts on Cloud Vulnerability and Risk Management

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

Internet Cloud server cabinet

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.

Recommendations for IoT Firmware Update Processes: Addressing complexities in a vast ecosystem of connected devices

By Sabri KhemissaIT-OT-Cloud Cybersecurity Strategist,Thales

IoT Firmware Update Processes report coverTraditionally, updating software for IT assets involves three stages: analysis, staging, and distribution of the update—a process that usually occurs during off-hours for the business. Typically, these updates apply cryptographic controls (digital signatures) to safeguard the integrity and authenticity of the software. However, the Internet of Things (IoT), with its vast ecosystem of connected devices deployed in many environments, introduces a host of complexities that drive the need for process re-engineering.

Developers, for instance, cannot ignore the fact that their IoT is integrating into a complex system and must consider how it can be securely updated while still co-existing with other products. Implementers, meanwhile, must take into account the entire (and complex) system, including the specific constraints of each IoT component.

Complicating matters further, there are many variations in the IoT systems that require software and firmware updates. For example, some IoT systems are often on the move and require relatively large downloads—such as connected vehicles. Other IoT systems, like smart home and building devices, are more static. Regardless, the factors associated with network saturation during downloads to hundreds or even thousands of devices must be considered. Equally important is the impact of failed firmware updates on consumers.

Mitigating Attacks with IoT Firmware Update Guidelines

To assist enterprises in navigating myriad complexities, CSA’s IoT Working Group compiled a set of key recommendations for establishing a secure and scalable IoT update process. Our latest report, “Recommendations for IoT Firmware Update Processes,” offers 10 guidelines for IoT firmware and software updates that can be fully or partially integrated. Each suggestion can be adapted and designed for custom firmware updates that recognize unique constraints, dependencies and risks associated with IoT products, and the complex systems they involve. These recommendations target not only developers and implementers, but also vendors who must design solutions with security in mind.

It’s our hope that in addressing this process, attack vectors that can be exploited by hackers are mitigated. You can read the full report to get a deeper sense of the challenges involved and for a set of best practices to overcome them.

PCI Compliance for Cloud Environments: Tackle FIM and Other Requirements with a Host-Based Approach

By Patrick Flanders, Director of Marketing, Lacework

PCI compliance for cloudCompliance frameworks and security standards are necessary, but they can be a burden on IT and security teams. They provide structure, process, and management guidelines that enable businesses to serve customers and interoperate with other organizations, all according to accepted guidelines that facilitate a better experience for end users.

Yet, when their IT environment is the cloud there is the additional challenge of trying to maintain the fairly static state of compliance in an environment where change is continuous. Every configuration change, addition of a new users, or transaction between data sources, even seemingly minor changes, can have hidden implications that when discovered, can render the organization non-compliant.

Payment Card Industry Data Security Standard (PCI DSS) is an industry standard intended to protect credit, debit, and cash card owners against theft of their personally identifiable information (PII), and to equip companies with best practices guidelines to secure payment processes and supporting IT systems. Originally established as a collaborative effort by American Express, Discover, MasterCard, Visa, and JCB, the original intent was to promote credit card activity for e-commerce.

Play it safe with PCI

PCI is intended to keep all those transactions safe, but with more money exchanging digital hands, there are more endpoints that PII and financial data touch. At the same time, more financial organizations are moving critical workloads to the cloud, which means they’re managing more change in the name of agility.

Many turn to open source tools to give them PCI monitoring. These tools are intended to provide high level file integrity monitoring, but they are only a surface layer. Data transacting inside the cloud environment, and activity moving outside of it can be targeted by hackers because these tools don’t target inconsistencies with configurations, and they’re not able to scale the demands of cloud workloads. Their focus is the network and they aren’t equipped to look at anything else in the cloud stack. Yet, without insight at a level where one can identify and evaluate every cloud action, there really can be no true understanding of what is at risk, to what degree the  organization is out of compliance, and there’s not ability to pinpoint where the problem is so it can be fixed.

Many IT groups piece together open source FIM tools along with legacy security tools like SIEMs and network-based detection systems. In an earlier era when there were fewer endpoints and control governance could be extended to the firewall, this was adequate. But financial organizations are now extending payment options through mobile apps and even IoT devices; the number of endpoints and potential holes in the system can grow exponentially.

This concept of monitoring and analyzing activity at every layer of the cloud stack maps to what’s necessary for today’s workloads and IT environments. Intrusion detection monitoring certainly is still necessary at the network layer, but it’s what’s happening with cardholder data as it travels through to different apps and repositories that can be complicated and hard to identify. Using a host-based system for monitoring network traffic throughout the infrastructure of the organization is mandatory because it’s functioning at the depth of configuration, access, and asset change levels.

Out of compliance, out of business

Being PCI-compliant is a necessity for any organization that facilitates ecommerce transactions with credit or debit cards. If ever there was a growth industry, it is online shopping. In 2017, ecommerce represented just 13% of all total retail sales, but 49% of all retail growth. Consumers made $454 billion worth of online purchases last year, and online sales grew 16% from the previous year. The consequences, therefore, of being out of compliance are huge – at best, fines and remediation will get you back in business. But if you really don’t have control over the activity within your cloud, you are liable to attacks and compliance issues that could eradicate customer trust, or altogether put you out of business.

To be effective at validating PCI compliance, it’s best to use an approach that analyzes cloud activity against normalized behavior to identify status of all PCI controls. Awareness of every event, every endpoint, and automatic identification of anomalies is critical to ensuring you are prepared with an effective PCI compliance framework.

Software-Defined Perimeter Architecture Guide Preview: Part 3

Part 3 in a four-part series

By Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

cyber security, lockThanks for returning for our third blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide. In this article, we’re focusing on the “Core SDP Concepts” section of the document, which introduces the underlying principles of SDP, and in which we explain the benefits that SDP provides. In the table below, we list five categories, and for each we explain several aspects of SDP that deliver benefits, along with some color commentary.

Information/Infrastructure Hiding

One of the key security benefits that SDP provides is that not only are the organization’s servers protected by the SDP Gateway, but the SDP infrastructure itself is secured against access by unauthorized users. This makes it safer to deploy SDP components in internet-facing roles, compared with traditional security infrastructure (such as VPNs) which are directly and easily accessible to attackers.

Aspect Benefits Threats Mitigated
Servers are “Blackened” The SDP components (Controller, Gateways) will not respond to any connections until the clients have been authenticated and authorized with the use of protocols such as Single Packet Authorization (SPA). External network attacks and cross domain attacks mitigated.
Mitigates Denial of Service attacks Internet-facing services are typically placed behind a ‘deny-all’ gateway/firewall, commonly an SDP Gateway, and are therefore protected from DoS attacks. The SDP Gateway itself is protected against DoS attacks by SPA (see above). Bandwidth DDoS.
Bad Packet detection The first packet to an accepting host (AH) from any other host is a SPA packet (or similar construct). If an AH receives any other packet, it is viewed as an attack, and future packets from that host can be rejected. External network and cross domain attacks quickly detected.

Mutual Two-way Encrypted Connections

Another key element of SDP is that all communications between components – typically the Client and the Controller & Gateways—are encrypted with mutually-validated TLS. This ensures that these elements can validate each other, ensuring the integrity of the system.

Aspect Benefits Threats Mitigated
Device Authentication The connections between all hosts must use mutual authentication to validate the device as an authorized member of the SDP. Ensures that connections cannot be initiated from invalid or unauthorized devices.
Disallows forged certificates Mutual authentication schemes pin certificates to a known valid root managed (or trusted) by the SDP. Reduces attacks from credential theft.
Disallows Man-in-the-middle attacks Mutual handshake ensures secure and tamper-proof communications between components. Prevents Man-in-the middle attacks.

SDP and the Need-to-Know Access Model

Because SDP is built upon a whitelist access policy model, users are only permitted access to those specific network resources that are permitted by policy—not to an entire subnet or network. The SDP philosophy is that application-level authentication is insufficient security, and that the ability to access a network resource—even without credentials—is in fact a privilege that should be explicitly granted.

Aspect Benefits Threats Mitigated
Allows fine-grained access control Only authorized users and devices are allowed to make connections to servers, based on access policies. Theft from external users from unknown devices is reduced.
Makes forensics easier All bad packets can be analyzed and tracked for forensics activities. Bad packets and connections are reduced.
Enforces device validation Device validation proves that the key is held by the proper device requesting connections. Threats from unauthorized devices are reduced and mitigates credential theft.
Protects from compromised devices Because users are only granted access to authorized applications and to no other ones, the threat of lateral movement from compromised devices is eliminated. Mitigates threats from lateral movement.

Dynamic Firewall

SDP acts as a logical (and in some implementations, actual) firewall, dynamically adjusting network access based on policies. This permits enterprises to create dynamic enclaves—essentially adapting user access to network resources based on membership attributes, such as directory group membership.

Aspect Benefits Threats Mitigated
Allows dynamic membership-based enclaves Access to protected resources enabled by dynamically creating and removing access rules. Mitigates network-based attacks.

Application Layer Access

The final key element of SDP is that users only have access to specified, permitted network resources (referred to as “Applications”, even though they may be admin-level services such as SSH or RDP). By preventing all unnecessary network-level access, organizations benefit by having a reduced attack surface, preventing reconnaissance (such as port scanning) by unauthorized users, and enabling the detection of attempted malicious activity.

Aspect Benefits Threats Mitigated
Eliminates broad network access With SDP, identities no longer have broad access to network segments or subnets. Devices can only access specific hosts and services permitted by policy. Minimizes attack surface. Eliminates port and vulnerability scanning by malware or malicious users
● Enables control of application and service access SDP can be used to protect different types of services, such as application and system services.

SDP systems can control which devices and applications are permitted to access specified services.

Limits attack surface, and prevents malware or malicious users from connecting to resources.

That’s a brief overview of the SDP Core concepts. In our next (and final) preview posting, we’ll be discussing the SDP Policy model. You can read our earlier installations here and here.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

Pwned Passwords – Have Your Credentials Been Stolen?

By Paul Sullivan, Software Engineer, Bitglass

hacker in a hoodie with credit cards, computer screenData breaches now seem to be a daily occurrence. In recent months, Have I Been Pwned (HIBP) introduced  Pwned Passwords, which allows you to securely check your password against a database of breach data. There are over 280 breaches in the database, and that’s only the tip of the iceberg. Breaches aren’t just a problem for the users who lose their data, but for the companies responsible for it.   

So how does all this data get breached?

Surely, it was some sinister character in a hoodie with extensive knowledge of computers, right? As it turns out, many of the data breaches came from misconfigured databases and Amazon S3 buckets that were left wide open for anyone who knows where to look. S3 is easy to use, which is great for security-conscious developers. However, it also makes it easy for someone who doesn’t understand security to toss some data into the cloud (so that it’s publicly viewable) and forget about it. As noted by Troy Hunt, the security researcher who runs HIBP, one company was breached because it stored personal data from IoT devices in MongoDB and Amazon S3 buckets with no credentials. It’s not just small, unorganized companies that make these mistakes either. Big corporations are losing track of their configurations, too.

Proper training is a good way to help with these problems, but it’s not always enough. Fortunately, a cloud access security broker (CASB) can help keep S3 and other cloud data secure by encrypting the data at rest. That way, even if data can be accessed by unauthorized parties, it is still unreadable and protected. A CASB can also provide auditing and analytics tools to help detect suspicious activity so that data breaches can be detected early as well as prevented from happening in the first place.

US CLOUD Act Drives Adoption of Cloud Encryption

By Rich Campagna, Chief Marketing Officer, Bitglass

police badge close-upThe US Clarifying Lawful Overseas Use of Data (CLOUD) Act was quietly enacted into law on March 23, 2018. I say quietly due to the controversial nature of how it was passed—snuck into the back of a 2,300 page Federal spending bill on the eve of Congress’ vote. While debate rages on about both the way the bill was passed, and about the wide latitude the Act gives to the President and the State Department, the fact remains that it has been signed into law, and organizations need to start planning how to respond. For many, both in the US and abroad, that planning has drawn increased interest in Cloud Access Security Brokers (CASBs), and specifically, in cloud encryption.

The CLOUD Act is meant to expedite law enforcement access to online/cloud data, specifically when that data is stored abroad. CLOUD is an update to the Electronic Communications Privacy Act (ECPA), which was passed in 1986, long before cloud was even a twinkle in any entrepreneur’s eyes. Under ECPA, the only way for the US and a foreign government to exchange such data was under a Mutual Legal-Assistance Treaty (MLAT), which must be passed by a 2/3 vote of the Senate.

(Enough Four or Five Letter Acronyms (FFLAs) in this post for you yet?)

Cloud(y) with a chance of encryption

Under the CLOUD Act, US Law Enforcement Agencies, at any level, can require tech companies to turn over user data, whether that data is stored in the US or abroad. CLOUD also allows the President and/or State Department to enter into law enforcement data sharing agreements with ANY foreign government without approval from Congress.

The CLOUD Act eliminates the need for the foreign entity to show probable cause or obtain a search warrant to request access to this information. While a cloud service provider (CSP) can deny this access, forcing the requester back to the much more time consuming MLAT process, there is no assurance to enterprises that they will do this, putting the onus on the enterprise to take additional security measures to control access to their data.

The fix? Cloud encryption, typically implemented via CASB solutions.

Choosing a cloud encryption solution

Cloud encryption allows an organization to leverage cloud applications, while at the same time encrypting sensitive data with keys that the enterprise controls. Such a scheme combines the mobility, productivity and agility advantages of using the cloud, with the security of a private data center.

Not only does encryption help mitigate concerns over rogue CSP admins or hacking attacks by malicious outsiders, but in the event that a CSP turns over data as part of a now lawful request by US or Foreign Government agency, that data is useless to the third party without the cooperation of the enterprise.

What to look for in an encryption solution?

1) Preservation of cloud app functionality

2) Full-strength, peer-reviewed encryption algorithms

3) Full enterprise control over encryption keys

Software-Defined Perimeter Architecture Guide Preview: Part 2

Part 2 in a four-part series

By Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

cyber security, lockThanks for returning for the second blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide (Read Part 1). In this article, we focus on the “SDP Scenarios” section of the document, which briefly introduces the primary scenarios for SDP, explains why organizations should consider adopting SDP, and lists the benefits that SDP delivers for that scenario.

This section is—by design—concise. We’re passionate about SDP and network security, and could write an entire novel on this topic (in which our hero, network security architect Reavis Macdonald, uses SDP to prevail against a malicious adversary and save his organization from a record-breaking GDPR fine!). Sadly, our editor assures us that such a story wouldn’t be a bestseller, and that our Architecture Guide should likewise err of the side of brevity.

In this blog posting, we’ve chosen to elaborate on several of the scenarios and to provide some color commentary. Let’s get started!

SDP Scenarios at a Glance

Scenario 1: Identity-Driven Network Access Control
Chart: SDP Scenario 1

This scenario is the heart of the value that an SDP architecture provides. It enables organizations to fundamentally change the way they’re viewing security—shifting away from IP addresses and subnets, and toward identities and business systems. This is more than a technical shift—at least, it should be more than that. We’ll discuss this more in the SDP Policy section in the main document, but SDP allows for policies to be described in terms that are meaningful to the business, yet are enforced by the network.

Scenario 2: Network MicrosegmentationChart: SDP Scenario 2

The concept of network microsegmentation—often part of a Zero Trust initiative—is driven by the imperative to enforce the principle of least privilege at the application and network level. But microsegmentation is only a means to an end. It requires a policy model, and a mechanism for automated enforcement of these microsegments in order to deliver efficient and effective value to the enterprise.

Shifting gears slightly, we now introduce several use cases that organizations commonly use to get started with Software-Defined Perimeter projects.

Scenario 3: Secure Remote Access (VPN Alternative)Chart: SDP Scenario 3

Virtual private networks (VPN), while widely deployed, nevertheless suffer from a variety of shortcomings that frequently drive organizations to consider the Software-Defined Perimeter as an alternative. In addition to being disruptive to the user experience, VPNs typically provide too-broad network access, exposing far more services and protocols than necessary. VPNs are also difficult or awkward to use when people need to concurrently access many distributed resources —either across data centers or cloud environments. And finally, VPNs are a point solution. Because they are only used for remote access, their access policies are by definition unable to apply to on-premises users. SDP solves all these problems with VPNs, providing a single consistent and user-friendly platform that secures access for both remote and on-premises users with fine-grained control of access rights.

Scenario 4: Third-party User AccessChart: SDP Scenario 4

Third-party access is another very common use case for SDP. While remote third-parties may fall under the VPN scenario, many organizations have considerable numbers of third-party users working on-premises. These users often need very specific (and limited) network access, while nevertheless using the same network as employees with broader access. A Software-Defined Perimeter provides a simple solution for this, which ensures that these third-party users have a consistently secured and managed set of network privileges, regardless of whether they are remote or on-premises.

Scenario 5: Enabling Secure Transition to IaaS Cloud EnvironmentsChart: SDP Scenario 5

Finally, we’re seeing many organizations leverage SDP to more easily and securely adopt IaaS cloud environments. Rather than relying on direct site-to-cloud connections (which provide too-broad network access), or traditional VPNs (which are awkward to use in multi-account or multi-site environments). SDP allows for precise access control to cloud environments, managed on a per-user basis.

Conclusion

We hope that this preview blog post gave you a good sense for some of the SDP scenarios, as well as a bit of expository context on our thinking around them. In our next blog posting, we’ll be reviewing the core concepts of the Software-Defined Perimeter , explaining their benefits, and listing some of the associated threats that they mitigate.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

CVE and Cloud Services, Part 1: The Exclusion of Cloud Service Vulnerabilities

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

The vulnerability management process has traditionally been supported by a finely balanced ecosystem, which includes such stakeholders as security researchers, enterprises, and vendors. At the crux of this ecosystem is the Common Vulnerabilities and Exposures (CVE) identification system. In order to be assigned an ID, vulnerabilities have to fulfill certain criteria. In recent times, these criteria have become problematic as they exclude vulnerabilities in certain categories of IT services that are becoming more and more common.

This is the first in a series of blogposts that will explore the challenges and opportunities in enterprise vulnerability management in relation to the increasing adoption of cloud services.

Common Vulnerabilities and Exposures

CVE® is a list of entries, each containing an identification number, a description, and at least one public reference for publicly known cybersecurity vulnerabilities[1].

CVEs are identifiers for security vulnerabilities that are—or are expected to become—public. Traditionally, they are assigned by one of two entities: The CNA (CVE Numbering Authority) that exists specifically for that piece of software (e.g. Microsoft, which covers Microsoft software) or a CNA that has been given coverage of said software (e.g. The Debian Project, Distributed Weakness Filing Project, and Red Hat all cover Open Source software to varying degrees). These CVEs are then published in the MITRE CVE database. Finally, they are consumed and republished by other organizations, often with additional information such as workarounds or fixes which makes tracking and remediating those vulnerabilities possible.

Customers of companies or organizations that are CNAs for their own products can be reasonably assured that CVE IDs are assigned to historical, current and future vulnerabilities found in those products.

CVE and Vulnerability Management

The CVE system is the linchpin of the vulnerability management process, as its widespread use and adoption allows different services and business processes to interoperate. The system provides a way for specific vulnerabilities to be tracked via the assignment of IDs. Enterprises, security researchers, penetration testers, software providers and even vulnerability scanning tools all use CVE IDs to track vulnerabilities in products. These IDs also allow important information regarding a vulnerability to be associated with it such as workarounds, vulnerable software versions, and Common Vulnerability Scoring System (CVSS) scores. Without the CVE system, it becomes difficult to track vulnerabilities in a way that allows the different stakeholders and their tools to interoperate.

Example of CVE and other associated information
Fig 1: Example of CVE and other associated information taken from CVEdetails.com (https://www.cvedetails.com/cve/CVE-2007-0994/)

CVE Inclusion Rules and Limitations

The decision to assign an ID to a vulnerability is governed by the Inclusion Rules. In order to assign a CVE ID to a vulnerability, the assigner has to take the vulnerability through the Inclusion Rules. Generally, only a vulnerability that fulfills all five criteria will be assigned an ID. For example, one of the Inclusion rules, INC3, states that a vulnerability should only be assigned a CVE ID if it is customer-controlled or customer-installable. A vulnerability in a Customer Relationship Management (CRM) software that is installed on a server owned and managed by an enterprise fulfills that requirement.

CVE Inclusion Rule INC3
Fig 2: Inclusion Rule INC3 taken from cve.mitre.org (https://cve.mitre.org/cve/editorial_policies/counting_rules.html)

INC3, as it is currently worded, is problematic for a world that is increasingly dominated by cloud services. In the past, this inclusion rule has worked well for the IT industry as most enterprise IT services have generally been provisioned with infrastructure owned by the enterprise. However, with the proliferation of cloud services, this particular rule has created a growing gap for enterprise vulnerability management. This is because cloud services, as we currently understand them, are not customer controlled. As a result, vulnerabilities in cloud services are generally not assigned CVE IDs. Information such as workarounds, affected software or hardware versions, proof of concepts, references and patches are not available as this information is normally associated to a CVE ID. Without the support of the CVE system, it becomes difficult, if not impossible, to track and manage vulnerabilities.

Conclusion

The Cloud Security Alliance and the CVE board are currently exploring solutions to this problem.

One of the first tasks is to obtain industry feedback regarding a possible modification of INC3 to take into account vulnerabilities that are not customer-controlled. Such a change would officially put cloud service vulnerabilities in the scope of the CVE system. This would not only allow vulnerabilities to be properly tracked, it would also enable important information to be associated with a service vulnerability.

Please let us know what you think about a change to INC3 and the resulting impact on the vulnerability management ecosystem in the comment section below or you can also email us.

Stay tuned for our next blog post where we will explore the impacts that the current Inclusion Rules have on enterprise vulnerability management.

[1] https://cve.mitre.org/

Software-Defined Perimeter Architecture Guide Preview

Part 1 in a four-part series.

By Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

cyber security, lockThe Software-Defined Perimeter (SDP) Working Group was founded five years ago, with a mission to promote and evangelize a new, more secure architecture for managing user access to applications. Since the initial publication of the SDP Specification, we’ve witnessed growing adoption and awareness throughout the industry. As practitioners, vendors, evangelists, and guides, we (as the SDP working group) have learned a great deal about SDP in practice, and wanted to capture and share that knowledge.

This was the driver for us to create the forthcoming Software-Defined Perimeter Architecture Guide. We’ve decided to publish a preview blog series here to obtain feedback on this work-in-progress artifact, and to spark conversation about SDP architectures and deployments. Ultimately, we intend the final published Architecture Guide—scheduled for publication in Q4 2018—to encourage broader (and more successful) adoption of SDP architectures.

Please join the conversation in the SDP working group here—we’re open to feedback, questions, or even just good restaurant recommendations. Thanks for reading this, and we look forward to engaging with you.

In this first blog posting, we’re going to walk through the SDP Architecture Guide outline and provide color commentary. Keep in mind that this document is still a work-in-progress, so the content and structure may well change prior to publication. Let’s dive in:

  • Introduction
    • Why We Wrote This Document
    • Target Audience
    • Goals
    • SDP Scenarios

In the introduction, we provide the motivation for the document, articulate who our target audience is, and explain our goals. Then, we enumerate SDP scenarios (AKA use cases), briefly explaining each one, and exploring the benefits that SDP provides in that scenario.

  • SDP, Zero Trust, and Google’s BeyondCorp

In addition to SDP, there is a lot of noise and activity in today’s marketplace around the Zero-Trust philosophy, and to some degree about Google’s internal BeyondCorp security initiative. In this section, we attempt to make sense of this and explain the similarities and differences between them.

  • SDP Overview
    • Core SDP Concepts
    • SDP Architecture
    • SDP Deployment Models
      • Client-to-Gateway Model
      • Client-to-Server
      • Server-to-Server Model
      • Client-to-Server-to-Client
      • Client-to-Gateway-to-Client
      • An Alternative Architecture: The Cloud-Routed Model

This section presents the foundational elements of SDP, including its core underlying concepts. We also dive into the SDP architecture and discuss each of the SDP deployment models.

    • Single-Packet Authorization
      • SPA Benefits

Single-Packet Authorization (SPA) is one of most important parts of SDP. By compensating for the fundamentally open (and insecure) nature of TCP/IP, SPA enables secure and reliable deployment of SDP Controllers and Gateways onto insecure and public networks. In this section, we analyze the SPA protocol, suggest some improvements, and expand upon its benefits to SDP.

    • SDP Policy Model
      • SDP Policy Overview
      • Policy Components

SDP, as a specification, is silent on a policy model. In this section, we introduce the elements that an SDP policy model should have and the corresponding capabilities that an SDP platform should be able to express. We conclude this section with a few example policies.

  • SDP in the Enterprise
    • Architecture Considerations
    • Security and IT Technologies
      • SIEM
      • Firewalls
      • Intrusion Detection/Prevention Systems
      • Virtual Private Networks
      • Next-Generation Firewalls
      • Identity and Access Management
      • VPNs
      • NAC
      • SDN
      • IDS / IPS
      • EMM / MDM
      • Web Application Firewalls
      • Cloud Access Security Brokers

This section introduces a simplified (but prototypical) enterprise model, exploring how each of the Security and IT technologies shown above are impacted by the deployment of SDP.

  • SDP Business Benefits

We conclude with the business benefits that SDP can deliver. This section, which will be constructed in a tabular format, will provide an overview of these benefits. We look forward to providing more detailed, quantified benefits and case studies in a future document.

Thanks for reading through the outline. In our next blog post in this series we’ll talk through the SDP Core Concepts table.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.

Convincing Organizations to Say “Yes to InfoSec”

By Jon-Michael C. Brook, Principal, Guide Holdings, LLC

security turned on in smartphoneSecurity departments have their hands full. The first half of my career was government-centric, and we always seemed to be the “no” team, eliminating most initiatives before they started. The risks were often found to outweigh the benefits, and unless there was a very strong executive sponsor, say the CEO or Sector President, the ideas would be shelved.

More recently, as a response to the security “no” team, IT staff started several “Shadow IT” projects. People began using cloud computing systems and pay-as-you-go strategies on a corporate credit card to quickly develop and roll-out projects before anyone in security could get a word in.

These “beg forgiveness” aspects hamstrung security on several projects, especially if a data leakage incident occurred or breach was in progress. What’s more, we weren’t unique in seeing shadow projects. These projects increasingly become the norm as IT staff looking to move initiatives forward come up against cybersecurity professionals hell-bent on maintaining security and, who know that in the event of a breach, heads could easily roll. Most likely theirs.

Tired of being seen as the “no” team? Here are three ideas that could reshape the value of security to your company as a whole:

Demonstrate Trust

Trust messages needs to come from outside of the department, even if it’s ghostwritten or created internally. Be it the CTO, CFO or CEO, there needs to be a bit of understanding that risk comes in many forms, and the Security Department takes all of those into account before approving or denying projects.

Many compliance frameworks have an HR or training domain, and some security departments successfully use this for mandatory training for topics like phishing. When a non-infosec colleague clicks on a fake attack, the trust point may be reiterated with a reminder of example fines and the costs. Breach notifications or PCI violations aren’t cheap after all.

Show Security as a Business Enabler

Share a couple of department wins, where the security team found involvement early in the process and added value to the program deployed. Look for examples like oAuth or Single Sign On (SSO) simplifying a portal’s usage or a project where business continuity planning or encryption helped pass an acceptance audit.

Demonstrating that security builds team success and is no longer the “no” department pays dividends.

Provide Educational Incentives

Lastly, extend the educational aspect beyond testing for ignorance. See if your organization offers reimbursement or even bonuses for security certifications, and stand-up internal lunch-and-learn or video conference preparation sessions. If your organization doesn’t provide an across-the-board financial incentive, maybe fund a raffle for five of the folks who pass the test to receive a spot bonus.

Hopefully, you’ll find these as an opportunity to impress upon the rest of the corporation the importance of the CISO’s office. There’s a long history of “no;” without efforts on the infosec staff’s part, that image will linger well past its truth.

Jon-Michael C. Brook, Principal at Guide Holdings, LLC, has 20 years of experience in information security with such organizations as Raytheon, Northrop Grumman, Booz Allen Hamilton, Optiv Security and Symantec. He is co-chair of CSA’s Top Threats Working Group and the Cloud Broker Working Group, and contributor to several additional working groups. Brook is a Certified Certificate of Cloud Security Knowledge+ (CCSK+) trainer and Cloud Controls Matrix (CCM) reviewer and trainer.

What Is a CASB?

By Dylan Press, Director of Marketing, Avanan

Email is the #1 attack vector. Cloud Account Takeover is the #1 attack target.
A CASB is the best way to protect against these threats.

cartoon of man asking What is a CASBGartner first defined the term Cloud Access Security Broker (CASB) in 2011, when most IT applications were hosted in the data center and few companies trusted the cloud. Most online services were primarily aimed at the consumer. At the time, CASB products were designed to provide visibility for so-called Shadow IT and limit employee access to unauthorized cloud services.

Today, organizations have embraced the cloud, replacing many of their datacenter applications with Software as a Service (SaaS) or moving much of their IT into infrastructure (IaaS) providers like Amazon or Azure. Instead of limiting access, CASBs have evolved to protect cloud-hosted data and provide enterprise-class security controls so that organizations can incorporate SaaS and IaaS into their existing security architecture.

CASBs provide four primary security services: Visibility, Data Security, Threat Protection, and Compliance. When comparing CASB solutions you should first make sure that they meet your needs in each of these categories.

Visibility

A CASB identifies all the cloud services (both sanctioned and unsanctioned) used by an organization’s employees. Originally, this only included the services they would use directly from their computer or mobile device, often called “Shadow IT“. Today, it is possible for an employee to connect an unsanctioned SaaS directly to a an approved SaaS via API. This “Shadow SaaS” requires more advanced visibility tools.

Shadow IT Monitoring: Your CASB must connect to your cloud to monitor all outbound traffic for unapproved SaaS applications and capture real-time web activity. Since nearly all SaaS applications send your users email notifications, your CASB should also scan every inbox for rogue SaaS communication to identify unapproved accounts on an approved cloud services.

Shadow SaaS Monitoring: Your CASB must connect to your approved SaaS and IaaS providers to monitor third-party SaaS applications that users might connect to their account. It should identify both the service as well as the level of access the user has provided.

Risk Reporting: A CASB should assess the risk level for each Shadow IT/Shadow SaaS connection, including the level of access each service might request (i.e. read-only access to a calendar might be appropriate, read-write access to email might not.) This allows you to make informed decisions and prioritize the applications that need immediate attention.

Event Monitoring: Your CASB should provide information about real-time and historical events in all of your organization’s SaaS applications. If you do not know how the applications are being used, you can not properly control them or properly assess the threats facing your organization.

Data Security

A CASB enforces data-centric security policies by offering granular access controls or encryption. It incorporates role-based policy tools, data classification and loss prevention technologies to monitor user activity and audit, block or limit access. Once, these were stand-alone systems. Today it is vital that they are integrated into the organization’s data policy architecture.

Data Classification: Your CASB should identify personally identifiable information (PII) and other confidential text within every file, email or message. Taking this further, it should be capable of applying policies to control how that sensitive information can be shared.

Data-Centric Access Management: Your CASB should allow you to manage file permissions based upon the user’s role and the type of data the file contains using cloud-aware enforcement options that work within the context of the cloud service.

Policy-based Encryption: Your CASB should be able to encrypt sensitive information across all your cloud services to ensure data security, even after files leave the cloud.

Threat Protection

A CASB protects cloud services from unwanted users or applications. This might include real time malware detection, file sandboxing or behavior analytics and anomaly detection. New threats require new protections, so the list should include anti-phishing, account-takeover detection and predictive (A.I.) malware technologies.

Anti-phishing Protection: Phishing attacks are the #1 source of data breaches every year, but few CASBs offer phishing protection for cloud-based email. For a technology that is protecting your cloud environment, anti-phishing is a must. It has been proven over and over again that your email provider is not a viable solution to the phishing problem.

Account Takeover Protection: Your CASB should monitor every user event (not just logins) to identify anomalous behavior, permission violations, or configuration changes that indicated a compromised account.

URL Filtering: Your CASB should check every email, file, and chat messages for malicious links.

Real Time Malware Detection: Your CASB should scan every email and file for active code and malicious content before it reaches the inbox.

Advanced Threat Sandboxing: Your CASB should test suspicious files in an emulation environment to detect and stop zero-day threats.

Compliance

Regulated organizations require auditing and reporting tools to demonstrate data compliance and a CASB should provide all the necessary auditing and reporting tools. More advanced solutions offer policy controls and remediation workflows that enforce regulatory compliance in real time for every industry, from GDPR and SOX to PCI and HIPAA..

SIEM Integration: Your CASB should collect and correlate user, file and configuration events from each cloud application installed in your organization’s environment and make them visible through your organization’s existing reporting infrastructure.

Auditing: Your CASB should have access to historical event data for retrospective compliance auditing as well as real-time reporting.

Enforcement: Your CASB should be able to move and encrypt files, change permissions, filter messages or use any number of cloud-native tools to ensure compliance through automated policies.

Email Security from Your CASB

As you may have noticed, across all the CASB criteria, email security is a major component. Can this really be that important? After all, so few CASBs include email security.

No matter the motivation, email continues to be the most common vector for enterprise breaches. Phishing and pretexting represented 98% of social incidents and 93% of breaches last year. Protection for the cloud must include protection for cloud-based email. Without cloud-based email security, a CASB is not truly providing full cloud security and is just acting as a simple Shadow IT tool.

Conclusion

While a solution doesn’t need to have every feature mentioned in this blog post in order to sell themselves as a CASB, they are the criteria that separate the CASBs that are complete security solutions from those that will need to be paired with additional security tools. If you want a CASB to act as your full security suite protecting your organization from cloud-borne threats then this will serve as a useful checklist.

Avoiding Cyber Fatigue in Four Easy Steps

By Jon-Michael C. Brook, Principal, Guide Holdings, LLC

coffee cup by an IT worker's screen indicating cyber fatigueCyber alert fatigue. In the cybersecurity space, it is inevitable. Every day, there will be a new disclosure, a new hack, a new catchy title for the latest twist on an old attack sequence. As a 23-year practitioner, the burnout is a real thing, and it unfortunately comes in waves. You’ll stay up on the latest and greatest for months on end. Take a couple weeks off at the wrong time of year, maybe around the big security conferences (think RSA or Blackhat/DEF CON), and you could spend 6 weeks catching back up. Everyone has a take, and without getting in front of the wave, the wheat may not be easy to separate from the chaff. How can you avoid–or at least lessen–the chance of missing the next question from a CISO while still maintaining a sense of sanity?

Where does the quest for knowledge transform into chasing your own tail?

Be picky

First and foremost, carefully vet your media input sources. Every source you sign-up for will inevitably add to the noise in your feed. Each follow, every like, even entering your email address for more information opens more avenues for daily discourse. Pick a few trusted sources of information, the innovators in your niche. For cybersecurity, Bruce Schneier (@schneierblog), Gene Spafford (@therealspaf) and Brian Krebs (@briankrebs) fit the mold. They’ll put enough content on the wire for a daily read in a short amount of time.

Set time limits

Set aside a period of time each day to catch up. It’s easy to read articles 24×7. Personally, I’m click baited any time I read a headline news article. My ADD increases my penchant for distraction, and suddenly three hours of my day passed without a tangible memo, report or other accomplishment.

Choose a duration that doesn’t wipe out the entire day, probably during the morning so you’ll have water cooler talk. Maybe it’s first thing before everyone comes in or you leave for the office, or try the train, lunch time. Find a daily podcast (Raf Los aka @Wh1t3Rabbit’s Down The Security Rabbit Hole is usually interesting) and listen to it during a morning exercise. Whatever it is, limit your alert time per day; they don’t call it Twitter for nothing.

Back-scatter and bit buckets

Be prepared to be bought and sold. The luckiest thing I ever did was buy my own domain name. I use unique email addresses for everything I sign up for and then forward the important ones into folders to keep my immediate inbox clean. It’s technically a back-scatter technique. If you have to make it past a marketing wall and provide information, don’t be afraid to unsubscribe, unfollow or remove access. Your contact info will be monetized, and most reputable marketing/distribution houses fear the legal ramifications of not complying with spam prevention acts. When someone doesn’t comply appropriately, simply point that individual address to the bit bucket.

The struggle is real

Add an additional account for friends and family threads for non-business hours. Co-workers at the office won’t think you’re wasting work time on personal pursuits. You also have a chance to create a work/life balance.

No one wants to live, breathe and die work. Cyber fatigue is real …

Jon-Michael C. Brook, Principal at Guide Holdings, LLC, has 20 years of experience in information security with such organizations as Raytheon, Northrop Grumman, Booz Allen Hamilton, Optiv Security and Symantec. He is co-chair of CSA’s Top Threats Working Group and the Cloud Broker Working Group, and contributor to several additional working groups. Brook is a Certified Certificate of Cloud Security Knowledge+ (CCSK+) trainer and Cloud Controls Matrix (CCM) reviewer and trainer.

 

Cloud Migration Strategies and Their Impact on Security and Governance

By Peter HJ van Eijk, Head Coach and Cloud Architect, ClubCloudComputing.com

cloud migration concept with servers in the cloud

Public cloud migrations come in different shapes and sizes, but I see three major approaches. Each of these has very different technical and governance implications.

Three approaches to cloud migration

Companies dying to get rid of their data centers often get started on a ‘lift and shift’ approach, where applications are moved from existing servers to equivalent servers in the cloud. The cloud service model consumed here is mainly IaaS (infrastructure as a service). Not much is outsourced to cloud providers here. Contrast that with SaaS.

The other side of the spectrum is adopting SaaS solutions. More often than not, these trickle in from the business side, not from IT. These could range from small meeting planners to full blown sales support systems.

More recently, developers have started to embrace cloud native architectures. Ultimately, both the target environment as well as the development environment can be cloud based. The cloud service model consumed here is typically PaaS.

I am not here to advocate the benefits of one over the other, I think there can be business case for each of these.

The categories also have some overlap. Lift and shift can require some refactoring of code, to have it better fit cloud native deployments. And hardly any SaaS application is stand alone, so some (cloud native) integration with other software is often required.

Profound differences

The big point I want to make here is that there are profound differences in the issues that each of these categories faces, and the hard decisions that have to be made. Most of these decisions are about governance and risk management.

With lift and shift, the application functionality is pretty clear, but bringing that out to the cloud introduces data risks and technical risks. Data controls may be insufficient, and the application’s architecture may not be a good match for cloud, leading to poor performance and high cost.

One group of SaaS applications stems from ‘shadow IT’. The people that adopt them typically pay little attention to existing risk management policies. These can also add useless complexity to the application landscape. The governance challenges for these are obvious: consolidate and make them more compliant with company policies.

Another group of SaaS applications is the reincarnation of the ‘enterprise software package’. Think ERP, CRM or HR applications. These are typically run as a corporate project, with all its change management issues, except that you don’t have to run it yourself.

The positive side of SaaS solutions, in general, is that they are likely to be cloud native, which could greatly reduce their risk profile. Of course, this has to be validated, and a minimum risk control is to have a good exit strategy.

Finally, cloud native development is the most exciting, rewarding and risky approach. This is because it explores and creates new possibilities that can truly transform an organization.

One of the most obvious balances to strike here is between speed of innovation and independence of platform providers. The more you are willing to commit yourself to an innovative platform, the faster you may be able to move. The two big examples I see of that are big data and internet of things. The major cloud providers have very interesting offerings there, but moving a fully developed application from one provider to another is going to be a really painful proposition. And of course, the next important thing is for developers to truly understand the risks and benefits of cloud native development.

Again, big governance and risk management are issues to address.

Peter van Eijk is one of the world’s most experienced cloud trainers. He has worked for 30+ years in research, with IT service providers and in IT consulting (University of Twente, AT&T Bell Labs, EDS, EUNet, Deloitte). In more than 100 training sessions he has helped organizations align on security and speed up their cloud adoption. He is an authorized CSA CCSK and (ISC)2 CCSP trainer, and has written or contributed to several cloud training courses. 

Top Security Tips for Small Businesses

By Jon-Michael C. Brook, Principal, Guide Holdings, LLC

employees discussing top small business security tipsMost small businesses adopt some sort of cloud offering, be it Software as a Service like Quickbooks or Salesforce, or even renting computers in Amazon Web Services or Microsoft’s Azure, in an Infrastructure as a Service environment. You get Fortune 50 IT support, including things that a small business could never afford, like building security and power fail-over with 99.999-percent reliability.

While cloud has great advantages, you must know your supply chain. Cloud providers use something called the shared responsibility model. Their risks and vulnerabilities become yours, so choosing a discount provider may open you up to compliance issues you never thought possible. That said, cloud does allow small business to focus on their competitively different things, leaving the technical aspects to others for essentially a pay-as-you-go utility computing.

In today’s increasingly complex security environment, following these three top security tips will go a long way to letting small business owners concentrate on running their business rather than keeping up with the latest security issues.

Something you know

Let’s talk about authentication, typically referred to as passwords. The first thing to establish is “something you know,” like a pin or password. The worst thing anyone can do in today’s day and age is use one username with one password. If any one of the sites used becomes compromised, the username/password combination will be sold on the Dark Web as a known combination. The lists are huge, but infinitely faster on other banking or e-commerce sites that implement effective security. This happened in the Yahoo! breach that nearly scuttled the Verizon acquisition a couple years ago, sending ripples throughout the web and forced resets by nearly every company in the world.

At the very least, use a unique password with between eight and (preferably) 16 characters. Characters are more than numbers and letters. The more of the keyboard utilized, the longer testing every combination in a brute force attack becomes.

Password managers such as LastPass or KeePass will make keeping these organized easier, and they synch across the various phone, laptop and desktop devices through cloud providers like Dropbox, Box and OneDrive. Many of these are now tying in to the “something you are” such as fingerprint or facial recognition.

Something you have

The next step up is a technique known as one-time passwords. They are much more than one-step effective and take the something you know to also include “something you have” in your mobile device. That’s why banks and financial trading firms incorporated the technology a few years ago.

As security gets better, so, too, do the hackers. SIM-card duplication and other attacks gave rise to something call soft tokens from Google Authenticator and Authy. The apps use a synchronized clock and the same hard mathematics in cryptography to make a system where the next number is easy to compute in the valid minute of use but the previous is impossibly difficult before the timer clicks over to the next one.

Currently, the most secure consumer password scenario comes from mathematics developed in the late 70’s called public key cryptography. This is the same technology in the soft token apps but in a purpose-built device, typically seen as a key fob or USB from manufacturers like Entrust, RSA or Yubi. This takes the one-time password to the next level by self-erasing on any attempt to get to the originally entered number.

To recap, secure passwords should be a combination of something you know, something you have and something you are, with an order of strength: Same Passwords -> Unique Passwords -> Txt Messages -> Soft Tokens (Authenticator/Authy) -> Hard Tokens (SecureID/RSA/Yubi)

Built-in, not bolted on

Lastly, follow your industry/vertical’s rules early.

The typical adage of “built-in, not bolted on” holds true for small business if you really want to make it in the long haul. It’s always easier to include security in the beginning than shoehorn it in afterwards. A small business may be fined for non-compliance to the point of bankruptcy by a few of the below regulations:

  • US Securities and Exchange Commission’s Sarbanes Oxley (SOX);
  • Payment Card Industry’s Data Security Standard (PCI-DSS);
  • Health Insurance Portability and Accountability Act (HIPAA);
  • Privacy controls by the US Federal Trade Commission’s Fair Credit Reporting Act (FCRA) and Children’s Online Privacy Protection Act (COPPA); and
  • European Union’s General Data Protection Directive (GDPR).

 Jon-Michael C. Brook, Principal at Guide Holdings, LLC, has 20 years of experience in information security with such organizations as Raytheon, Northrop Grumman, Booz Allen Hamilton, Optiv Security and Symantec. He is co-chair of CSA’s Top Threats Working Group and the Cloud Broker Working Group, and contributor to several additional working groups. Brook is a Certified Certificate of Cloud Security Knowledge+ (CCSK+) trainer and Cloud Controls Matrix (CCM) reviewer and trainer.

Updated CCM Introduces Reverse Mappings, Gap Analysis

By Sean Cordero, VP of Cloud Strategy, Netskope

CCM logoSince its introduction in 2010, the Cloud Security Alliance’s Cloud Control Matrix (CCM) has led the industry in the measurement of cloud service providers (CSP). The CCM framework continues to deliver for CSPs and cloud consumers alike a uniform set of controls to measure the security readiness of a cloud-centric security program. It continues to be the industry standard used to measure, evaluate, and inform risk, information security, and audit professionals on the best practices for securing cloud services.

Consistent with the CSA’s commitment to driving greater trust, assurance, and accountability across the information risk and security industry, this latest expansion to the CCM incorporates the ISO/IEC 27017:2015, ISO/IEC 27018:2014, and ISO/IEC 27002:2013 controls, and introduces a new approach to the development of the CCM and an updated approach to incorporate new industry control standards.

Core to this release of the ISO 27017:2015, 27018:2014, and 27002:2013 reverse mappings and gap analysis were two additional goals defined by the CSA and the CCM Working Group:

  1. Improve the ease of operationalization and measurement for all new controls.
  2. Increase the flexibility for CSPs and cloud consumers adopting additional control frameworks while retaining alignment with the core CCM controls.

Improved ease of operational usage and measurement

The avoidance of overly prescriptive control statements has been central to the CCM’s control development philosophy. This approach was required to avoid duplication across other control frameworks and to avoid rework for security and audit professionals. While this approach is reflected in the language of the CCM, this intentional lack of specificity has made it, at times, challenging to fully integrate into architectural and validation efforts. To address this within the language for the newly developed controls two key changes were made—first, to the alignment of the core of the research team and second, to the method of delivery for new controls.

First, two working group sub-teams were created and leaders of each identified. One group specific to information risk management and the other for audit and control measurement. To ensure that both teams brought to bear their collective expertise across the entire revision, each team then collaborated on the review of the work product of the other team, which has led to the most comprehensive and well-defined release of the CCM to date.

The information security team was led by Ai Ping Foo. Her team focused on the identification and creation of new controls and mappings with a focus on ensuring the incorporation of these controls across security architectures.

The assurance team was led by Ahmed Maaloul, whose team drove the creation of the new controls and mappings with a focus on ensuring control clarity, ease of measurement, and reproducibility for audit and assurance professionals.

Improved flexibility and delivery for new controls

This latest release of the Cloud Controls Matrix introduces reverse mappings and gap analysis to the CCM program. We believe that this approach allows organizations to continue their alignment to the core CCM standard while giving the option of further expanding their controls without disruption to any STAR certification efforts underway or existing certifications.

As the CCM framework continues to mature we are confident it will give security, audit, and assurance professionals the most flexibility for control identification without compromising the existing CCM controls.

The CCM continues to define the standard for trust, assurance, and control for security, audit, and compliance analysts when conducting operations in the cloud. This latest release reflects the CSA’s and the CCM Working Group’s continued commitment towards ease of use, flexibility, and uniformity across the multiple disciplines which enable trusted cloud operations.

The success of the CCM continues to be the result of the dedicated professionals within the CCM Working Group. This latest release would not have been possible without the expertise, focus, and collaboration of the following working group members:

Security Team Leader: Ai Ping Foo

Assurance Team Leader: Ahmed Maaloul

CCM Working Group Volunteers:

Ai Ping Foo

Adnan Dakhwe

Ahmed Maaloul

Angela Dogan

Alejandro del Rio Betancourt

Bunmi Ogun

Chris Sellards

Chris Shull

Eric Tierling

Josep Bardallo

Kazuki Yonezawa

Kelvin Arcelay

Madhav Chablani

Masashiro Morozumi

Mariela Rengel

Mohin Gulzar

Muswagha Katya

Noutcha Gilles

Puneet Thapliyal

Shahid Sharif

Saraj Mohammed

M. Reid Leake

William Butler

Download the latest version of the CSA Cloud Control Matrix.

Sean Cordero has over 18 years of IT and Information Risk Management. He has held senior security executive roles at leading bio-technology, financial, retail, and consulting organizations. Cordero is the Chair of the CSA’s Cloud Control Matrix Working Group and serves as the Co-Chair of the CSA’s Consensus Assessments Initiative Questionnaire. Cordero was honored by the CSA with the Ron Knode Service Award in 2013 and inducted as a CSA Research Fellow in 2016. Cordero is a certified CISSP, CISM, CISA and CRISC.