Saturday Morning Security Spotlight: Jail Breaks and Cyberattacks

By Jacob Serpa, Product Marketing Manager, Bitglass

Here are the top cybersecurity stories of recent weeks:

— Man attempts prison break through cyberattacks
— Mailsploit allows for perfect phishing attacks
— 1.4 billion credentials found in dark web database
— Starbucks WiFi hijacks connected devices
— Hackers target cryptocurrency employees for bitcoins

Man attempts prison break through cyberattacks

In an attempt to acquire an early release for his imprisoned friend, a man launched a thought-out cyberattack against his local prison. Through a combination of phishing and malware, the hacker successfully stole the credentials of over 1,000 of his local county’s employees. While he was ultimately caught, he did gain access to the jail’s computer system.

Mailsploit allows for perfect phishing attacks
By exploiting bugs in numerous email clients, a researcher demonstrated how to make an email appear as though it were sent from any email address. Affected clients include Outlook 2016, Thunderbird, Apple Mail, Microsoft Mail, and many more. While some were quick to patch their offerings, others are refusing to address their vulnerabilities.

1.4 billion credentials found in dark web database
Dark web researchers have uncovered a massive database listing 1.4 billion unencrypted credentials. The database contains usernames and passwords from LinkedIn, Pastebin, RedBox, Minecraft, and much more. Individuals who reuse passwords across multiple accounts (and their employers) are put at massive risk by the discovery.

Starbucks WiFi hijacks connected devices
The WiFi of a Starbucks in Argentina was recently found to hijack connected devices to mine for cryptocurrency. The event highlights the dangers of connecting to public networks – even those that may appear trustworthy. Unfortunately, many individuals believe the desire for convenience to outweigh the need for security, putting their employers at risk.

Hackers target cryptocurrency employees for bitcoins
Hackers from what is believed to be the Lazarus Group are targeting high-level employees of cryptocurrency firms – presumably to steal bitcoins. Attacks begin with phishing email attachments that, when opened, launch malware in the targets’ systems.

To defend against phishing, account theft, malware, and other security threats, organizations must adopt complete security solutions. Learn how to achieve comprehensive visibility and control over data by reading the Definitive Guide to Cloud Access Security Brokers.

Adding Value to Native Cloud Application Security with CASB

By Paul Ilechko, Senior Security Architect, Cedrus

Many companies are starting to look at the Cloud Access Security Broker (CASB) technology as an extra layer of protection for critical corporate data as more and more business processes move to the cloud.

CASB technologies protect critical corporate data stored within cloud apps and among their preventative and detective controls, a key feature is the ability to encrypt data stored within cloud apps.

At the highest level, the concept is quite simple – data flowing out of the organization is encrypted, as it is stored in the cloud. However, in practice there are nuances in the configuration options that may have impact on how you implement encryption in the cloud.

Most users will start with a discovery phase, which typically involves uploading internet egress logs from firewalls or web proxies to the CASB for examination. This provides a detailed report of all cloud application access, usually sorted by a risk assessment that is specific to the CASB vendor doing the evaluation (all of the major CASB vendors have strong research teams who do the Cloud service risk evaluation for you, so that you don’t have to).

This enables a company to start thinking about the policy needed to protect themselves in the cloud, and also to drive conversations with the business departments using the cloud services, to get an understanding of why they are using them, and if they really need them to get their jobs done. This can drive a lot of useful considerations, such as:

  • Is this service safe, or is it putting my business/data at risk?
  • If it is creating risk, what should I do about? Can I safely block it, or will it cause an issue with my business users?
  • If my business users need this functionality, are there better options out there that achieve the same goals without the risk?

This discovery, assessment and policy definition phase can take some time, possibly weeks or even months, before you are ready to take the next step into a more active CASB implementation. To summarize the ways in which CASB can be integrated into a more active protection scheme:

  • CASBs provide API level integration with many of the major SaaS, PaaS and IaaS services, allowing for out-of-band integration that perform functions like retroactive analysis of data stored in the cloud, or near real-time data protection capabilities than can be implemented in either a polling or a callback model.
  • CASBs typically provide an in-line proxy model of traffic inspection, where either all, or some subset, of your internet traffic can be proxied in real time, and decisions can be made on whether to allow the access to proceed. This can incorporate various Data Loss Prevention (DLP) policies, can check for malware, and can perform contextual access control based around a variety of factors, such as user identity, location, device, time of day, etc. – as well as sophisticated anomaly and threat protection using data analytics, such as unexpected data volumes, non-typical location access, and so on.
  • For users who are leery about using a CASB inline for all traffic, particularly when that traffic is already traversing a complex stack of products (firewall, web proxy, IPS, Advanced Threat Protection…), many CASB vendors also provide a “reverse proxy” model for integration with specific sanctioned applications, allowing for deeper control and analysis that integrates the CASB with the cloud service using SAML redirection at login time.

Policy-based encryption
Many platforms, such as Salesforce with its Salesforce Shield capability, provide the ability to encrypt data. With Shield, for example, this can be at either at the file or field level. However, Shield is configured at the organization level. Most companies that use Salesforce will probably have created multiple Salesforce Orgs. It’s likely that you want to define policy consistently across organizations, and even across multiple applications, such as Salesforce and Office365.

A CASB can provide you with the capability to define policy once and apply it many times. You have the option to use the CASB’s own encryption, or in some cases to make use of the CASB’s ability to use API integration to interact with the platform’s own native tools (e.g., some CASB’s are able to call out to Salesforce Shield to perform selective encryption as required by policy). The CASB can protect your data no matter where in an application it resides: in a document, in a record, or in a communication channel such as Chatter. (The CASB can, of course, provide these capabilities for many applications, we are just using Salesforce here as an example.)

Continuous Data Monitoring
A CASB can provide real-time or near-real time monitoring of data. It can use API’s to retroactively examine data stored in a cloud provider looking for exceptions to policy, threats such as malware, or anomalies such as potential ransomware encryptions. It can act as a proxy, examining data in flight and taking policy based actions at a granular level.

Threat and anomaly recognition
CASB’s typically provide strong capabilities around threat protection and anomaly recognition. Using advanced data science techniques against a “big data” store of knowledge, they can recognize negligent and/or malicious behavior, compromised accounts, entitlement sprawl and the like. The exact same set of analytics and policies can be applied across a range of service providers, rather than forcing you to attempt it on a piecemeal basis.

Cross-cloud activity monitoring
Because a CASB can be used to protect multiple applications, it can provide a detailed audit trail of user and administrative actions that traverse actions across multiple clouds, and which can be extremely useful in incident evaluation and forensic investigations. The CASB acts as a single point of activity collection, which can then be used as a channel into your SIEM.

So, to summarize: while many of the major cloud service providers have added interesting and useful security features to their applications, a CASB can add significant additional benefit by streamlining, enhancing and consolidating your security posture across a wide range of applications.

It Could Happen To You

By  Yael Nishry, Vice President/Business Development, Vaultive; Arthur van der Wees LLM, Arthur’s Legal; and Jiri Svorc LLM, Arthur’s Legal

For organizations around the world, implementing state-of-the-art security and personal data protection (using both technical and organizational measures) is now a must. In the wake of the recent Equifax incident, this article outlines why data security and privacy accountability is important and how organizations can responsibly manage their sensitive data.

You Got Equifax-ed!
On September 7, 2017, Equifax disclosed arguably the most severe personal data breach ever, affecting up to 143 million US consumers, between 400,000 and 44 million British consumers, and approximately 100,000 Canadian residents. The global consumer credit reporting agency announced that between March and July 2017 hackers were able to access consumers’ personal data, including names, social security numbers, birthdates as well as driver license numbers. In addition, the details of up to 209,000 credit cards were reportedly compromised.

While previous breaches have exposed the details of more people overall, the Equifax incident is significant due to the highly sensitive nature of the leaked information. Although some of the data is of temporary nature and can easily be refreshed (such as credit card numbers), other types are more difficult to change (including addresses or social security numbers). It’s not difficult to imagine why the leak of unchangeable “lifetime data, including customers’ names and birthdates, is extremely alarming to consumers. As a result, the incident has been followed by significant media outcry, inspired the introduction of legislation, and sparked investigations from the FTC and FBI. Not to mention the value of Equifax’s stock fell by a third in the days following the disclosure.

A Case for Encryption
Due to the extent of the Equifax data breach, it is not surprising that it took less than two weeks for the first privacy regulator to take legal action. The attorney general of the state of Massachusetts filed a law suit against Equifax pursuant to the state’s consumer protection laws.

The complaint alleges that the credit reporting agency failed to adequately secure its portal after the public disclosure of a major vulnerability in the open-source software used to build its consumer redress portal and failed to maintain multiple layers of security around consumer data. Also, it argues that the credit rating agency violated the law by keeping Massachusetts’ residents’ information accessible in an unencrypted form on a part of its network accessible from the internet. Given the fact that the company collects and aggregates the information of over 800 million individual consumers worldwide, it is disturbing to learn that encryption was not being used effectively by its IT security team in this case. This is even more surprising when viewed through the lens of the Equifax’s main business activities: acquiring, compiling, analyzing, and selling sensitive personal data.

The Massachusetts’ claim alleges that Equifax’s market position and business nature obliges the company to go beyond the regulations’ minimum requirements and “implement administrative, technical, and physical safeguards […] which are at least consistent with industry best practices.” As one of the most commonly used and best-practice security measures, the encryption of sensitive consumer data should have been ensured.

From What If …
What if the Equifax incident had occurred a year later?

In the first months of 2018, several important pieces of new legislation will go into effect in the EU, including the General Data Protection Regulation (GDPR) and the directive concerning measures for a high common level of security of network and information systems across the Union (NIS Directive). Both laws bring about significant changes in the domain of data protection and cybersecurity and introduce a new set of requirements for companies to comply with. Had the Equifax breach occurred in July 2018, the agency would likely face legal claims pursuant to GDPR and NIS Directive.

The NIS Directive aims to achieve a high common level of security of network and information systems within the EU. In doing so, its provisions apply to all providers of digital services active in the EU as well as operators of essential services active in the Union. GDPR, on the other hand, places stringent data protection and security obligations on anyone handling personal data of EU citizens. Similar to NIS Directive, the GDPR requires companies processing personal data to implement appropriate technical and organizational measures that ensure a level of security appropriate to the risk, taking into account state-of-the-art costs, purposes, and impact. In this respect, the regulation regards encryption as one of the appropriate technical measures to be implemented. Failing to encrypt customers’ data properly, Equifax would likely be non-compliant with its relevant provisions.

In addition, GDPR requires an organization to notify authorities within 72 hours of becoming aware of the breach, so it’s Equifax’s disclosure of the data breach more than six weeks after it occurred would certainly not comply with the obligation to notify the supervisory authority without undue delay.  Once again, had the incident occurred a year later, failing to act in accordance with the law could result in Equifax being charged with penalty fees of up to 4% of its total worldwide annual turnover, which would amount to about EUR 130 million, per breach.

Data Protection Impact Assessment
Both breaches could have been prevented had Equifax diligently carried out the Data Protection Impact Assessment (DPIA) required by the EU GDPR. This is a legal requirement under the GDPR for organizations processing personal data in a way which is likely to result in high risk to the rights and freedoms of natural persons. Though it is not only important from the legal compliance perspective, the DPIA can also provide organizations with a systematic description of personal data processing, including special categories of data, an assessment of its necessity and processing, as well as identification of risks and the measures in place to address them. In other words, DPIA serves as a valuable strategy and validation tool for testing and assuring data and security strategy. It provides organizations with many benefits, including a potential for structural savings, data minimization, and scalability of the business model. Hence, based on the extent of the incident it is clear that a diligently carried out DPIA would and should have raised plentiful red flags for Equifax to address.

It Could Happen to You
Given the thousands of UK and Canadian citizens who were also affected by the Equifax incident, some have claimed that the filing of the lawsuit by the Massachusetts attorney general may just be the tip of the iceberg. Indeed, it may as well be the case. At the same time, however, there remain thousands of organizations processing sensitive personal data which constitutes an essential part of their business. Irrespective of the new legislation entering into application in 2018, if organizations have not started addressing the issues of security and protection of personal data of their customers, the Equifax saga may in the end only serve as an overture to a swiftly developing and extensive narrative featuring a growing number of unprepared characters.

Avoid a Breach: Five Tips to Secure Data Access

By Jacob Serpa, Product Marketing Manager, Bitglass

Although the cloud is a boon to productivity, flexibility, and cost savings, it can also be a confusing tool to utilize properly. When organizations misunderstand how to use it, they often expose themselves to threats. While there aren’t necessarily more threats when using the cloud, there are different varieties of threats. As such, organizations need to employ the below cloud security best practices when they make use of applications like SalesforceOffice 365, and more.

Password123
When an employee uses one insecure password across multiple accounts, it makes it easier for nefarious parties to steal corporate information wherever that password is used. In light of this, organizations should require unique passwords of sufficient length and complexity for each of a user’s SaaS accounts. Additionally, requiring employees to change their passwords regularly – perhaps every other month – can provide an additional layer of security.

Authenticate or Else
Whether it occurs through employee carelessness, a breach from a hacker, or a combination of the two, credential compromise is a large threat to organizations. As detecting rogue accounts can be a challenging endeavor, multi-factor authentication should be employed as a means of verifying that accounts are being used by their true owners. Before allowing a user to access sensitive data, organizations should require a second level of verification through an email, a text message, or a hardware token (a unique physical item carried by the user).

Data on the Go
The rise of BYOD (bring your own device) has given individuals access to corporate data from their unmanaged mobile devices and, consequently, exposed organizations to new threats. In light of this, enterprises must secure BYOD, but do so in a way that is simple to deploy and doesn’t harm device functionality or user privacy. This is typically done through data-centric, agentless security. With these tools, organizations can secure data on unmanaged mobile devices in a timely, secure, non-invasive fashion.

Put the Pro in Proactive
Oftentimes, as more and more data moves to the cloud, organizations fail to monitor and protect it accordingly. They adopt after-the-fact security that can allow months of data exfiltration before detecting any threats or enabling remediation. However, in a world with regulatory compliance penalties, well-informed consumers, and hackers who can steal massive amounts of data in an instant, a reactive posture is not adequate. Organizations should adopt proactive cloud security platforms that enable real-time detection of malicious activity. Failure to utilize tools that respond to threats the moment they occur can prove disastrous for an organization’s security, finances, reputation, and livelihood.

More Malware More Problems
With all of the cloud applications and devices storing, uploading, and downloading data, malware has a number of attack surfaces it can use to infect organizations. If a single device uploads a contaminated file to the cloud, it can spread to connected cloud apps and other users who download said file. While protecting endpoints from malware is necessary, it is no longer sufficient. Today, organizations must deploy anti-malware capabilities that can defend from threats at upload, threats at download, and threats already resting in cloud applications. Defenses must lie in wait wherever data moves.

Now What?
Cloud access security brokers provide a breadth of capabilities that can enable the above best practices. Download the Definitive Guide to CASBs to learn more.

MSP: Is Your New Digital Service Compliant?

By Eitan Bremler, VP Marketing and Product Management, Safe-T Data

Offering managed services seems like an easy proposition. You offer IT services for companies that don’t have the infrastructure to support their own, bundle in services like cloud storage or remote desktop access, then sit back and watch the money roll in.

Of course, that’s a dramatic oversimplification of how an MSP works, especially because this description contains a rather substantial omission — security. As an MSP, you’re handling the sensitive digital data from dozens of companies. Not only are you subject to well-known compliance regimes such as PCI-DSS and HIPAA, you might also be subject to newer regulations from the NY DFS or soon, the GDPR.

Some of these regimes are known quantities and others not so much, but if you fail to follow them, one thing is certain — your customers will quickly cut ties. How can managed service providers provide secure and compliant digital services?

MSPs Are Likely to Be Covered by Multiple Overlapping Compliance Regimes
Each managed services provider is likely to be covered by at least one of the following four compliance standards, based on who they do business with.

  • If you touch PHI from a healthcare provider, you are subject to HIPAA and must execute a Business Associate Agreement (BAA) before you’re allowed to start working with them.
  • If you process credit card numbers, or store credit card numbers for another company, you are subject to PCI-DSS. Companies who process more credit cards are subject to stricter standards, so it pays to keep track of how many cards you’re processing.
  • If you work with a company that’s under the jurisdiction of New York’s Department of Financial Services, then you will be subject to compliance regulations recently laid down by the DFS. These regulations mandate a number of security controls, backed up by regular audits.
  • If you work with a company that deals with the data of EU citizens, or do business with an EU company direction, then after May 25th, 2018, you will be subject to the GDPR.

These bullets are outlines, not guidelines. If you’re unsure as to whether your organization is affected by one or more of these compliance regimes, it’s best to talk to a lawyer. Also remember that it’s extremely common to believe that you’re unaffected by a particular compliance standard, only to receive a nasty surprise. For example, you might also be affected by the GLBA, FISMA, FERPA, or SOX, depending on your target market or business model.

Different Compliance Regimes Will Affect Different Companies in Different Ways
Here’s where it gets tricky. Many compliance regimes specify that companies secure their most valuable information in different ways, or follow different procedures in the event of a breach. HIPAA, for example, mandates that companies report data breaches within 60 days, but PCI-DSS and the GDPR both give companies just 72 hours to report breaches.

In 2010, the SANS Institute recommended that companies affected by multiple compliance regimes adopt what they referred to as a Mother of All Control Lists (MOACL). The process of creating an MOACL is perhaps easier to describe than it is to carry out.

Step One: Understand all of the various compliance regimes that one is subject to.
Step Two: Understand the best practice recommendations of those regimes.
Step Three: Attempt to adhere to the strictest recommendation from every compliance regime. E.G., if HIPAA mandates a 60-day breach reporting schedule, but PCI-DSS mandates three days, then companies should plan on having three days to submit breach reports in every case.

The concept of an MOACL is a great starting point for MSPs (and any business subject to multiple compliance regimes) but the drawback is that it may take a great deal of time to implement. Fortunately, the MOACL can be replicated with tools that turn compliance into a turnkey service.

Decoding NYCRR Part 500: What Finance Institutions Need to Know

By Kyle Watson, Identity and Access Management and Cloud Access Security Broker Expert, Cedrus

For those of you in organizations subject to NYDFS oversight, you are probably aware of 23 NYCRR 500, a new set of cybersecurity requirements that went into effect this past March for financial services companies operating in New York. Its purpose is to address the heightened risk of cyberattacks by nation-states, terrorist organizations and independent criminal actors.

So who does NYDFS NYCRR Part 500 apply to? If your company operates in New York, the first question you should ask is: Does my company meet the definition of a Covered Entity? According to the DFS website, the following entities are subject to compliance:

  1. Licensed lenders
  2. State-chartered banks
  3. Trust companies
  4. Service contract providers
  5. Private bankers
  6. Mortgage companies
  7. Insurance companies doing business in New York
  8. Non-U.S. banks licensed to operate in New York

As the year comes to an end, it is imperative that your organization is ready to comply and file the annual DFS Certification of Compliance, which is due on February 15, 2018.

In Financial Services, you should already have a set of policies, procedures, standards and, guidelines based on a Commons Security Framework (ISO, COBIT, etc.) that allow you to perform risk assessments and comply to regulatory mandates. Policies drive the necessary processes and procedures that govern your day to day operations, enabling your business to be secure and compliant. You should be reinforcing this with all types of people that have access to your systems and data through awareness training during onboarding and on a periodic basis.

There has been an increasing focus on compliance at the data level of protection. NYDFS classifies this data as Non-Public Information. It is necessary for organizations to have data protection strategies in place to protect employees, partners, and customers. The increase of threats and breaches have ignited legislative bodies to subsequently issue regulations to ensure that companies are behaving in a way that mitigates risk. Many new regulations have come into play in recent years. Prior to NYDFS 23 NYCRR 500,  there was the EU General Data Protection Regulation (EU-GDPR) in 2016, and Service Org Control (SOC) in 2011 (formerly SSAE16 in 2010 and SAS70 in 1992).  A robust risk-based approach to data protection means that your company should have a short distance to get to compliance, but each new regulatory mandate introduces changes that must be considered in data protection, visibility, and reporting to the executive level.

NYDFS started in March 2017, and there was a transitional period that ended in August 2017, with the deadline for filing an extension ending in September 2017. The timeline starts getting more specific as the new year rolls out with the first annual certification due on February 18, 2018. Following the early 2018 deadline is a timeline for implementation of specific components of the regulatory mandate required controls.

The NYDFS 23 NYCRR 500 Timeline

There are five key things that you need to do immediately if you have not done so:

  1. Appoint a Chief Information Security Officer (CISO) with specific responsibilities
  2. Ensure that senior management files an annual certification confirming compliance with the NYCRR Part 500 regulations
  3. Conduct regular assessments, including penetration testing, vulnerability assessments, and risk assessments
  4. Deploy key technologies including encryption, multi-factor authentication, and others
  5. Ensure your processes allow you to report to NYDFS within 72 hours any cybersecurity event “that has a reasonable likelihood of materially affecting the normal operation of the entity or that affects Nonpublic Information.”

What makes this new set of regulations unique is that it requires companies to comply with more specific, enforceable rules than they currently use. It also differs from existing guidance, frameworks, and regulations in that it has a broad definition of protected information, an increased oversight of third parties, calls for the timely destruction of NPI (Non-Public Information) and prompt notification of a cybersecurity event (72 hours). Entities are also mandated to maintain unaltered audit trails and transaction records and submit annual certification.

So How Is Compliance Measured?
A recent survey by the Ponemon Institute reports that 60 percent of respondents (who primarily work in their organizations’ IT, IT security and compliance functions) believe this regulation will be more challenging to implement than GLBA, HIPAA, PCI DSS,  and SOX. What is unique about NYDFS NYCRR Part 500 is that it obligates entities to comply with more specific and enforceable rules that they currently face. It differs from existing guidance, frameworks, and revelations in several meaningful ways:

  • Broad definition of protected information
  • Broad oversight of third parties
  • Timely destruction of NPI (nonpublic information)
  • Prompt notification of cybersecurity event (72 hours)
  • Maintaining unaltered audit trails and transactions records
  • Annual certification (first submission due on February 15, 2018)

As an NYDFS covered entity, an organization must certify that they have implemented the controls as outlined in the requirements of NYCRR Part 500.  In order to certify, the Board of Directors or Senior Officers must have evidence that appropriate governance, processes, and controls are in place.  This evidence is provided through the Risk Assessment.

There are nine major components of the NYDFS regulation that should drive an entity’s Risk Assessment:

  1. Program
  2. Policies
  3. Training
  4. Third-party Risk Management
  5. Vulnerability & Penetration Testing
  6. Logging and Monitoring
  7. Access Security
  8. Multi-factor Authentication
  9. Encryption

It is important to note that the Risk Assessment must be conducted periodically, updated as necessary, and conducted in accordance with written policies and procedures so that it’s a defined and auditable process.  Finally, it must be well documented. Meeting compliance will be a challenge for some, even though financial services companies have expected the new cybersecurity regulation for some time. Some of the challenges that we foresee in achieving NYDFS compliance are:

  • Keeping senior management and key stakeholders involved in the planning and reporting process
  • Running regular risk assessments, noting deficiencies from each assessment, and adjusting as necessary
  • Validating that within your technology line-up, you are covered. Are key technologies such as encryption and multifactor authentication in place?
  • Reporting within 72 hours. As you review your incident process, assess whether you can respond to the reporting requirements for cybersecurity events within the required 72 hour period.

In addition to protecting customer data and fortifying the information systems of financial entities, another significant attribute of NYDFS 23 NYCRR Part 500 is its widening the net of regulated data protection.  NYDFS is driving organizations to properly secure sensitive Non Public Information, known as NPI. Even though NPI classification is not new (GLBA was one of the first regulations to introduce personal data security data requirements for NPI), the NYDFS regulation has a more prescriptive approach than others – it requires entities to implement policies, procedures, and technologies to comply.

NPI acts as an umbrella over PII (Personally Identifiable Information) and PHI (Protected Health Information). All three data types have their nuances though, so even if you secure your PII and PHI, it doesn’t mean that your NPI is 100% secure and that you’re in compliance.  Take some time to evaluate NPI in your organization – see section 500.01.g for the NYDFS definition of NPI.

Being Compliant with NYDFS Through the Proper Protection of NPI
Cloud Access Security Broker (CASB) and Identity and Access Management (IAM) are two key components that can help an organization with its overall compliance strategy for Part 500, and ultimately improve your ability to protect sensitive data and avoid a breach.

CASB is a key security technology for NYDFS compliance

CASB provides critical features necessary in the control strategy for cloud applications:

  • Discover what cloud applications are in use as well as where specific data is going to cloud applications, such as PII, PHI, or NPI
  • Invoke actions such as alerting the user or blocking a specific app or activity, like upload or download, based upon unusual behavior through user behavior analytics
  • Detect data compromises and anomalies and take action while informing other security systems like Security Information and Event Management (SIEM) for event correlation and forensics
  • Provide vendor risk analysis and ranking including important items such as recent breaches and incidents, infrastructure used to serve the application, and the vendor’s policies around data ownership and destruction
  • Control access over critical cloud apps and data using the context of device, data, location, or other behavioral risk information
  • Monitor authorized users to track their application use


IAM is also a key security technology for NYDF

When it comes to IAM, the value lies in Access Privileges and Multi-Factor Authentication. IAM enterprise tools can tie access provisioning to job functions and job roles, which allow you to manage to the minimum necessary/least privilege. They can also provide access attestation features so you can review access to applications with regulated information on a periodic interval, and approve or revoke the access based upon a need-to-know basis. Finally, IAM technology is invoked to trigger the need for Multi-Factor Authentication in applications and services (typically in conjunction with a third-party Multi-Factor Authentication end-user solution such as Google Authenticator or DUO).


CASB and IAM work together to provide critical controls for cloud applications

Achieving and maintaining cybersecurity compliance is a complicated process, but it doesn’t have to be a difficult or stressful one. Find out more by downloading our  Road to CASB: Key Business Requirements 2.0 whitepaper, designed to provide you with requirements that you can use as input consideration for your CASB initiative.

 

AWS Cloud: Proactive Security and Forensic Readiness – Part 1

By Neha Thethi, Information Security Analyst, BH Consulting

Part 1 – Identity and Access Management in AWS
This is the first in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to identity and access management in AWS.

In a recent study by Dashlane regarding password strength, AWS was listed as an organization that supports weak password rules. However, AWS has numerous features that enable granular control for access to an account’s resources by means of the Identity and Access Management (IAM) service. IAM provides control over who can use AWS resources (authentication) and how they can use those resources (authorization).

The following list focuses on limiting access to, and use of, root account and user credentials; defining roles and responsibilities of system users; limiting automated access to AWS resources; and protecting access to data stored in storage buckets – including important data stored by services such as CloudTrail.

The checklist provides best practice for the following:

  1. How are you protecting the access to and the use of AWS root account credentials?
  2. How are you defining roles and responsibilities of system users to control human access to the AWS Management Console and API?
  3. How are you protecting the access to and the use of user account credentials?
  4. How are you limiting automated access to AWS resources?
  5. How are you protecting your CloudTrail logs stored in S3 and your Billing S3 bucket?

Best-practice checklist

1) How are you protecting the access to and the use of AWS root account credentials?

  • Lock away your AWS account (root) login credentials
  • Use multi-factor authentication (MFA) on root account
  • Make minimal use of root account (or no use of root account at all if possible). Use IAM user instead to manage the account
  • Do not use AWS root account to create API keys.

2) How are you defining roles and responsibilities of system users to control human access to the AWS Management Console and API?

  • Create individual IAM users
  • Configure a strong password policy for your users
  • Enable MFA for privileged users
  • Segregate defined roles and responsibilities of system users by creating user groups. Use groups to assign permissions to IAM users
  • Clearly define and grant only the minimum privileges to users, groups, and roles that are needed to accomplish business requirements.
  • Use AWS defined policies to assign permissions whenever possible
  • Define and enforce user life-cycle policies
  • Use roles to delegate access to users, applications, or services that don’t normally have access to your AWS resources
  • Use roles for applications that run on Amazon EC2 instances
  • Use access levels (list, read, write and permissions management) to review IAM permissions
  • Use policy conditions for extra security
  • Regularly monitor user activity in your AWS account(s).

3) How are you protecting the access to and the use of user account credentials?

  • Rotate credentials regularly
  • Remove/deactivate unnecessary credentials
  • Protect EC2 key pairs. Password protect the .pem and .ppk file on user machines
  • Delete keys on your instances when someone leaves your organization or no longer requires access
  • Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys
  • Delegate access by using roles instead of by sharing credentials
  • Use IAM roles for cross-account access and identity federation
  • Use temporary security instead of long-term access keys.

4) How are you limiting automated access to AWS resources?

  • Use IAM roles for EC2 and an AWS SDK or CLI
  • Store static credentials securely that are used for automated access
  • Use instance profiles or Amazon STS for dynamic authentication
  • For increased security, implement alternative authentication mechanisms (e.g. LDAP or Active Directory)
  • Protect API access using Multi-factor authentication (MFA).

5) How are you protecting your CloudTrail logs stored in S3 and your Billing S3 bucket?

  • Limit access to users and roles on a “need-to-know” basis for data stored in S3
  • Use bucket access permissions and object access permissions for fine-grained control over S3 resources
  • Use bucket policies to grant other AWS accounts or IAM

 

For more details, refer to the following AWS resources:

Next up in the blog series, is Part 2 – Infrastructure Level Protection in AWS – best practice checklist. Stay tuned.

Let us know if we have missed anything in our checklist!

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written. Also, please note that this checklist is for guidance purposes only.

 

What Will Software Defined Perimeter Mean for Compliance?

By Eitan Bremler, VP Marketing and Product Management, Safe-T Data

Your network isn’t really your network anymore. More specifically, the things you thought of as your network — the boxes with blinking lights, the antennae, the switches, the miles of Cat 5 cable — no longer represent the physical reality of your network in the way that they once did. In addition to physical boxes and cables, your network might run through one or more public clouds, to several branch offices over a VPN, and even through vendor or partner networks if you use a managed services provider. What’s more, most of the routing decisions will be made automatically. In total, these new network connections and infrastructure add up to a massive attack surface.

The software defined perimeter is a response to this new openness. It dictates that just because parts of your infrastructure are connected to one another, that doesn’t mean they should be allowed access. Essentially, the use of SDP lets administrators place a digital fence around parts of their network, no matter where it resides.

Flat Networks Leave Data Vulnerable
Where security is concerned, complicated networks can be a feature, not a bug. For companies above a certain size, who must protect critical data, a degree of complexity in network design is recommended. For example, can everyone in your company access the shared drive where you store your cardholder’s information? This is bad practice — what you need to adopt is a practice known as segmentation, recommended by US-CERT.

Any network in which every terminal can access every part of the network is known as a “flat” network. That is, every user and application can access only those resources which are absolutely critical for them to do their jobs. A flat network operates by the principle of most privilege — everyone gets access to anything. In other words, if a hacker gets into an application, or an employee goes rogue, prepare for serious trouble.

Flat networks are also a characteristic of networks lacking a software defined perimeter.

Create Nested Software Defined Perimeters for Extra Security
Flat networks introduce a high level of risk for flat organizations, but the use of SDP can eliminate this risk. The software-defined approach can create isolated network segments around applications and databases. What’s more, this approach doesn’t rely on either physically rewiring a network or creating virtual LANs, both of which are time-consuming processes.

This approach is already used in public cloud data centers, where thousands of applications that must not communicate with one another must coexist on VMs that are hosted on the same bare-metal servers. The servers themselves are all wired to one another in the manner of a flat network, but SDN keeps their networks or data from overlapping.

Do You Need SDP in Order to Be Compliant?
Software defined perimeters are strongly recommended for security, but it’s actually not necessary for compliance — yet. PCI DSS 3.2 doesn’t require network segmentation — in the main because the technology is still in its relative infancy, and is not yet accessible to every company. Those companies that can segment their networks, however, do receive a bit of a bonus.

If you manage to segment your network appropriately, only the segments of your network that contain cardholder data will be subject to PCI audit. Otherwise, the entirety of a flat network will be subject to scrutiny. Clearly, it’s easier to defend and secure a tiny portion of your network than the entire thing. Those who learn the art of network segmentation will have a massive advantage in terms of compliance.

Look for Software-Defined Perimeter Solutions
Solutions using the SDP method will help organizations set Zero Trust boundaries between different applications and databases. These are effectively more secure than firewalls, because they obviate the necessity of opening ports between any two segmented networks. This additional security feature lets companies reduce the scope of PCI without changing

Your Morning Security Spotlight: Apple, Breaches, and Leaks

By Jacob Serpa, Product Marketing Manager, Bitglass

Here are the top cybersecurity stories of recent weeks:

–Apple’s High Sierra has massive vulnerability
–Survey says all firms suffered a mobile cyberattack
–Morrisons liable for ex-employee leaking data
–S3 misconfiguration leaks NCF customer data
–Imgur reports 2014 breach of 1.7 million credentials

Apple’s High Sierra has massive vulnerability
Apple’s latest operating system, High Sierra, was found to have a massive vulnerability. By typing the username “root” and leaving the password blank, devices running the operating system could be accessed, offering a way to steal data and upload malicious software.

Survey says all firms suffered a mobile cyberattack
In Check Point’s survey of 850 businesses around the world, all were found to have experienced a mobile cyberattack. This demonstrates the dangers of enabling unsecured BYOD and mobile data access. Additionally, the report contains surprising statistics on mobile malware, man-in-the-middle attacks, and more.

Morrisons liable for ex-employee leaking data
The supermarket chain Morrisons was recently found liable for a breach caused by an ex-employee in 2014. In 2015, the employee was sentenced to eight years in jail for maliciously leaking the payroll data of 100,000 fellow employees. However, Morrisons will now be held responsible, as well.

S3 misconfiguration leaks NCF customer data
The National Credit Federation (NCF) is reported to have leaked sensitive data belonging to tens of thousands of its customers. The information, which included bank account numbers and scans of Social Security cards, was leaked through an Amazon S3 misconfiguration that allowed complete public access to certain data.

Imgur reports 2014 breach of 1.7 million credentials
Imgur recently discovered that it suffered from a breach in 2014 that led to the compromise of 1.7 million users’ email addresses and passwords. The attack serves as an example of the fact that breaches (and ongoing data theft) can take years to detect.

Clearly, organizations that fail to protect their sensitive information will suffer the consequences. Learn how to achieve comprehensive visibility and control over data by reading the solution brief for the Next-Gen CASB.

Electrify Your Digital Transformation with the Cloud

By Tori Ballantine, Product Marketing, Hyland

Taking your organization on a digital transformation journey isn’t just a whimsical idea; or something fun to daydream about; or an initiative that “other” companies probably have time to implement. It’s something that every organization needs to seriously consider. If your business isn’t digital, it needs to be in order to remain competitive.

So if you take it as a given that you need to embrace digital transformation to survive and thrive in the current landscape, the next logical step is to look at how the cloud fits into your strategy. Because sure, it’s possible to digitally transform without availing yourself of the massive benefits of the cloud. But why would you?

Why would you intentionally leave on the table what could be one of the strongest tools in your arsenal? Why would you take a pass on the opportunity to transform – and vastly improve – the processes at the crux of how your business works?

Lightning strikes
In the case of content services, including capabilities like content management, process management and case management, cloud adoption is rising by the day. Companies with existing on-premises solutions are considering the cloud as the hosting location for their critical information, and companies seeking new solutions are looking at cloud deployments to provide them with the functionality they require.

If your company was born in the digital age, it’s likely that you inherently operate digitally. If your company was founded in the time before, perhaps you’re playing catch up.

Both of these types of companies can find major benefits in the cloud. Data is created digitally, natively — but there is still paper that needs to be brought into the digital fold. The digitizing of information is just a small part of digital transformation. To truly take information management to the next level, the cloud offers transformative options that just aren’t available in a premises-bound solution.

People are overwhelmingly using the cloud in their personal lives, according to AIIM’s State of Information Management: Are Businesses Digitally Transforming or Stuck in Neutral? Of those polled, 75 percent use the cloud in their personal life and 68 percent report that they use the cloud for business. That’s nearly three-quarters of respondents!

When we look at the usage of cloud-based solutions in areas like enterprise content management (ECM) and related applications, 35 percent of respondents leverage the cloud as their primary content management solutions; for collaboration and secure file sharing; or for a combination of primary content management and file sharing. These respondents are deploying these solutions either exclusively in the cloud or as part of on-prem/cloud hybrid solutions.

Another 46 percent are migrating all their content to the cloud over time; planning to leverage the cloud but haven’t yet deployed; or are still experimenting with different options. They are in the process of discerning exactly how best to leverage the power of the cloud for their organizations.

And only 11 percent have no plans for the cloud. Eleven percent! Can your business afford to be in that minority?

More and more, the cloud is becoming table stakes in information management. Organizations are growing to understand that a secure cloud solution not only can save them time and money, but also provide them with stronger security features, better functionality and larger storage capacity.

The bright ideas
So, what are some of the ways that leveraging the cloud for your content services can digitally transform your business?

  • Disaster recovery. When your information is stored on-premises and calamity strikes — a fire, a robbery, a flood — you’re out of luck. When your information is in the cloud, it’s up and ready to keep your critical operations running.
  • Remote access. Today’s workforce wants to be mobile, and they need to access their critical information wherever they are. A cloud solution empowers your workers by granting them the ability to securely access critical information from remote locations.
  • Enhanced security. Enterprise-level cloud security has come a long way and offers sophisticated protection that is out of reach for many companies to manage internally.

Here are other highly appealing advantages of cloud-based enterprise solutions, based on a survey conducted by IDG Enterprise:

  • Increased uptime
  • 24/7 data availability
  • Operational cost savings
  • Improved incident response
  • Shared/aggregated security expertise of vendor
  • Access to industry experts on security threats

Whether you’re optimizing your current practices or rethinking them from the ground up, these elements can help you digitally transform your business by looking to the cloud.

Can you afford not to?

AWS Cloud: Proactive Security & Forensic Readiness

This post kicks off a series examining proactive security and forensic readiness in the AWS cloud environment. 

By Neha Thethi, Information Security Analyst, BH Consulting

In a time where cyber-attacks are on the rise in magnitude and frequency, being prepared during a security incident is paramount. This is especially crucial for organisations adopting the cloud for storing confidential or sensitive information.

This blog is an introduction to a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment.

Cyber-attack via third party services
A number of noteworthy information security incidents and data breaches have come to light recently that involve major organisations being targeted via third-party services or vendors. Such incidents are facilitated in many ways, such as a weakness or misconfiguration in the third-party service, or more commonly, a failure to implement or enable existing security features.

For example, it has been reported that several data breach incidents in 2017 occurred as a result of an Amazon S3 misconfiguration. Additionally,  the recent data breach incident at Deloitte appears to have been caused by the company’s failure to enable two-factor authentication to protect a critical administrator account in its Azure-hosted email system.

Security responsibility
Many of our own customers at BH Consulting have embraced the use of cloud, particularly Amazon Web Services (AWS). It is estimated that the worldwide cloud IT infrastructure revenue has almost tripled in the last four years. The company remains the dominant market leader, with an end-of-2016 revenue run rate of more than $14 billion.  It owes its popularity to its customer focus, rich set of functionalities, pace of innovation, partner and customer ecosystem as well as implementation of secure and compliant solutions.

AWS provides a wealth of material and various specialist partners to help customers enhance security in their AWS environment. A significant part of these resources is a shared responsibility model for customers, to better understand their security responsibilities based on the service model being used (infrastructure-as-a-service, platform-as-a-service or software-as-a-service).

Figure 1: AWS Shared Responsibility Model

When adopting third-party services, such as AWS, it is important that customers understand their responsibility for protecting data and resources that they are entrusting to these third parties.

Security features
Numerous security measures are provided by AWS, however, awareness of relevant security features and appropriate configuration, are key to taking full advantage of these measures. There may be certain useful and powerful features that a customer may be unaware of.  It is the responsibility of the customer to identify all the potential features so as to determine how best to leverage each one, if at all.

Five-part best practice checklist
The blog series will offer the following five-part best practice checklists, for proactive security and forensic readiness in AWS Cloud.

  1. Identity and Access Management in AWS
  2. Infrastructure Level Protection in AWS
  3. Data Protection in AWS
  4. Detective Controls in AWS
  5. Incident Response in AWS

Stay tuned for further installments.

Four Important Best Practices for Assessing Cloud Vendors

By Nick Sorensen, President & CEO, Whistic

When it comes to evaluating new vendors, it can be challenging to know how best to communicate the requirements of your vendor assessment process and ultimately select the right partner to help your business move forward — while at the same time avoiding the risk of a third-party security incident. After all, 63 percent of data breaches are linked to third parties in some way. In fact, we all recently learned about how an Equifax vendor was serving up malicious code on their website in a newly discovered security incident.

The Whistic team has done thorough research on what a good vendor assessment process looks like and how to keep your organization safe from third party security threats. In the following article, we’ll outline a few of these best practices that your organization can follow in order to improve your chances of a successful vendor review. Of course, there will still be situations that you must address in which a vendor is either not prepared to respond to your request or isn’t willing to comply with your process. However, we’ll share some tips for how to best respond to these situations, too.

But before we get started, keep these three keys in mind:

  1. Time your assessments: The timing of the assessment will be the single greatest leverage you have in getting a vendor to respond. Keep in mind that aligning your review with a new purchase or contract renewal is key.
  2. Alert the vendor ASAP: The sooner a vendor is aware of a review the better. Plan ahead and engage early and get executive buy-in from your team to hold vendors accountable to your policy. If your business units understand that you have a policy requirement to review every new vendor, they can help set expectations during the procurement process and eliminate last-minute reviews.
  3. Don’t overwhelm your vendors: Unnecessary questions or requests for irrelevant documentation can slow the process down significantly. Be sure to revisit your questionnaire periodically and identify new ways to customize questions based on vendor feedback. You may find that after conducting several security reviews that there may be ways to improve the experience for both parties.

Personalize the Communication
At Whistic, we’ve had a front row seat to the security review processes of companies all across the world and a wide range of use cases. We’ve seen firsthand how much of a difference personalized communication can make in creating a more seamless process for all involved, especially third party vendors who are or hope to be trusted partners to your business.

With this in mind, we strongly recommend sending a personalized email to each vendor when initiating a new questionnaire request to supplement the email communication that they will receive from any software you utilize. This can help alleviate concerns the vendor may have about the assessment process and should help to improve turnaround times on completed questionnaires. Even with the automated communication support from a third party security platform, the best motivator for your vendor to complete your request may be a friendly reminder from you or the buyer that the sales process is on hold until they complete the assessment.

Deliver Expectations Early
Assuming that your vendor already understands that you are going to need to complete a security review on them, the best time to help them understand your expectations is either right before or right after you initiate a request via your third party security platform.

When doing so, keep the following in mind as you have a phone call or draft an email to your vendor to introduce the vendor assessment request:

  • Set The Stage: Let your vendor know about the third party security platform that your organization uses and that it is required method for completing your security review process.
  • Give Clear Direction: Specify a clear deadline and any specific instructions for completing the entire security review — not just the questionnaire.
  • Provide Resources: Provide information for the best point of contact who can answer questions they may have throughout the process. It’s also a good idea to let them know that your third party security platform may reach out if they aren’t making progress on their vendor assessment.

Utilize an Email Template
Whether you use a customized template created by your team or a predefined template (such as the one Whistic provides to its customers), it’s worth spending a few minutes upfront to standardize the communication process. This will save you time in the long-run and allow you to deliver a consistent message to each of your vendors.

Respond to Vendor Concerns
It isn’t uncommon for vendors, particularly account executives, to try and deflect a security review as they know it has the potential to delay the sales/renewal process. They may also have questions about sharing information through a third party security platform as opposed to emailing that information to you. We know from experience how frustrating this can be for all involved, so below are a two tips for handling pushback:

  • Preparation: If you are getting repeated pushback from vendors, review the “Keys to Success” outlined at the beginning of this article and explore additional ways to adopt those best practices.
  • Complexity, Relevance, and Length: These items can be among the reasons why vendors complain about your security review process. Consider periodically revisiting your questionnaire and consider adding additional filter logic to limit the number of questions asked of each vendor or make the question sets more relevant to vendor that is responding.

These are just a few things to consider as you look to assess your next cloud vendor. What else have you found helpful as you have approached this responsibility at your company?

 

Your Morning Security Spotlight

By Jacob Serpa, Product Marketing Manager, Bitglass

The top cybersecurity stories of the week revolved around malware and breaches. Infections and data theft remain very threatening realities for the enterprise.

400 Million Malware Infections in Q3 of 2017
In the last few months, malware has successfully infected hundred of millions of devices around the world. As time passes, threats will continue to become more sophisticated, effective, and global in reach. To defend themselves, organizations must remain informed about current malware trends.

Fileless Attacks Are on the Rise
It is estimated that 35 percent of all cyberattacks in 2018 will be fileless. This kind of attack occurs when users click on unsafe URLs that run malicious scripts through Flash, for example. Rather than rely solely on security measure that only monitor for threatening files, the enterprise should adopt solutions that can defend against zero-footprint threats.

Terdot Malware Demonstrates the Future of Threats
The Terdot malware, which can surveil emails and alter social media posts in order to propagate, is serving as an example of the evolution of malware. More and more, threats will include reconnaissance capabilities and increasing sophistication. Hackers are looking to refine their methods and contaminate as many devices as possible.

Spoofed Black Friday Apps Steal Information and Spread Malware
In their rush to buy discounted products, many individuals are downloading malicious applications that masquerade as large retailers offering Black Friday specials. As information is stolen from affected devices and malware makes its way to more endpoints, businesses that support bring your own device (BYOD) must be mindful of how they secure data and defend against threats.

What to Do in the Event of a Breach
ITPro posted an article on how organizations should respond when their public cloud instances are breached. Rather than assume that cloud app vendors perfectly address all security concerns, organizations must understand the shared responsibility model of cloud security. While vendors are responsible for securing infrastructure and cloud apps themselves, it is up to the enterprise to secure data as it is accessed and moved to devices. As such, remediation strategies vary depending on how breaches occur (compromised credentials versus underlying infrastructure being attacked).

Clearly, the top stories from the week were concerned with what can go wrong when using the cloud. To combat these threats, organizations must first understand them. From there, they can adopt the appropriate security solutions. To take the first step and learn more about threats in the cloud, download this report.

IT Sales in the Age of the Cloud

By Mathias Widler, Regional Sales Director, Zscaler

The cloud is associated not only with a change in corporate structures, but also a transformation of the channel and even sales itself. Cloudification makes it necessary for sales negotiations to be held with decision-makers in different departments and time zones, with different cultural backgrounds and in different languages. The main challenge: getting a variety of departments to the negotiating table, and identifying the subject matter expert among many stakeholders.

To communicate with different decision-makers, sales reps must switch quickly from their roles as salespeople to global strategists and account managers. Today’s salespeople sell services, not boxes. They must also explain how the service can benefit the business, instead of simply touting its features.

The new sales process highlights the need for new skills and qualifications in the sales department, as we explain below.

Selling business value
A decade ago, it was important to get a company’s security person excited about new technology during a sales pitch. But the days of simply closing a deal by convincing the responsible person or admin to buy the product are long gone. What is needed today is a holistic winning strategy, which starts by explaining the business advantages of a solution to a potential customer.

Today, the work starts long before the sales person picks up the phone. The pitch must be individually tailored to the current and future business requirements of each organization. True cloud solutions facilitate an integrated implementation of digital transformation processes – providing the foundation for a better user experience, more flexibility, lower costs, and much more. The cloud is sold not as an end in itself, but as a result of the above-mentioned effects. Therefore, the service must be adapted to the requirements of the prospective customer and presented convincingly.

Reaching out to more decision-makers
Besides the CIO, many more stakeholders now need to be brought to the table, including the application-level department, network managers, security contacts, project managers, data protection officers, and potentially the works council. The decision-making processes involved in the purchase of a cloud service are therefore much more complex and protracted. According to a recent CEB report, in just two and half years, the average number of decision-makers per project increased by 26 percent from 2013 to 2016.

Today, the average number of persons involved in a buying decision is 6.8. A group of stakeholders is no longer as homogeneous as before, because it is much more difficult to reach consensus among a diverse group of senior executives. What is more, in addition to internal decision-makers, external decision-makers can also play a decisive role. This increases still further the number of stakeholders, and adds to the complexity of the decision-making processes.

To reach a consensus, a winning strategy must be acceptable to all decision-makers with various backgrounds. The demands placed on sales have become inherently more complex in the age of the cloud. Sales people who were used to sell an appliance have to reinvent themselves as strategists, who need to balance conflicting interests and find common ground, in particular with respect to the introduction of the cloud.

Dealing with long sales cycles
CEB points out that the sales process up to closing has been prolonged by a factor of two, as it involves efforts to overcome differences of opinion as well as fine-tuning to reach a consensus. For the project to succeed, departments that have previously made separate decisions now have to come together at the table. To sell a cloud service today, sales professionals must be able to convince the entire buying center that their solution is the right one. It’s helpful if sales people can identify the subject matter expert in a negotiating team, whose vote will ultimately be decisive.

Globalization also means that the salesperson needs to take cultural sensitivities into account. It is no longer a rarity for an IT department of a global corporation to be based in Southern or Eastern Europe due to available expertise and the wage level of the workforce.

At the same time, salespeople should not lose sight of how they can act as catalysts to speed up a decision. Which different types of information do the stakeholders need? Where does leverage come into play to move the team to the next step? What conflicting interests need to be balanced?

Understanding new principles: capex vs opex, SLAs and trust
Before a company can benefit from the much-promised advantages of the cloud, it must rely on the expertise of sales, which makes the value-add clear across the organization. This is all the more important as the cloud service is not as “tangible” as hardware. The process of building trust is handled through service level agreements, reference customer discussions, and, where necessary, credit points for non-performance. A portal can provide insight into the availability of the service level, which highlights the continuous availability of the service or describes service failures.

As capital expenditures (capex) are converted into operating expenses (opex), another issue, which needs to be made clear, comes into play with respect to license agreement-based procurement. The businesses pay only for use of the services, which can be adjusted as and when required. Regarding the data protection provisions applicable to the cloud service, consulting with the works council and understanding its respective concerns is recommended. A contract on data processing establishes the legal framework for cooperation with the cloud provider.

Once the effectiveness of the cloud approach can be demonstrated by a proof-of-concept, the cloud has basically won. After all, a test environment can be set up within a very short time. The maintenance cost for maintaining and updating of hardware solutions is thus a thing of the past, which should be a compelling argument for every department from an administrative point of view.

What makes a successful salesperson?
In a nutshell, the sales manager has to convince the customer of the business value of a cloud-based solution – at all levels of the decision-making process. In this context, the personal skills to engage in multi-faceted communication with a wide range of contacts are much more relevant than before.

Emotional intelligence, as well as technical expertise in project management, should also be thrown into the mix. It’s important to take an active role at all levels of the sales process, taking account of the fact that the counterarguments of the prospective customer have to be addressed at various points on the path to digitization.

Project management plays an increasingly important role in the age of the cloud, such as keeping in touch with all stakeholders and monitoring the progress of the negotiations. Even after the project is brought to a successful conclusion, sales has to continue to act as an intermediary, and remain available as a contact to ensure customer satisfaction. This is because services can be quickly activated – and canceled.

For this reason, it’s important in the new cloud era to continue to act as an intermediary and maintain contact with the cloud operations team in the implementation phase. The salesperson of a cloud service is in a sense the account manager, who initiates the relationship and keeps it going.

Days of Our Stolen Identity: The Equifax Soap Opera

By Kate Donofrio, Senior Associate, Schellman & Co.

The Equifax saga continues like a soap opera, Days of Our Stolen Identity.  Every time it appears the Equifax drama is ending, a new report surfaces confirming additional security issues.

On Thursday, September 12, NPR reported that Equifax took down their website this time based on an issue with fraudulent Adobe Flash update popups on their site, initially discovered by an independent security analyst, Randy Abrams.[1]  Did the latest vulnerability mean Equifax continued with their inadequate information technology and security practices, even after being breached?  Or is it an even worse possibility, that their machines were not completely remediated from the original breach?

As it turns out, Equifax claimed they were not directly breached again, rather one of their third-party service providers responsible for uploading web content to Equifax site for analytics and monitoring was at fault.  According to Equifax, the unnamed third-party service provider uploaded the malicious code to their site.  It appears the only thing Equifax has been consistently good at is placing blame and pointing a finger in other directions.

Equifax needs to take responsibility after all they hired the service provider, are responsible for validating compliance of their service provider’s actions within their environment, and still hold the overall responsibility of their information.  This is a huge lesson for any company who attempts to pass blame to a third-party.

For those that have not been keeping track, below demonstrates a rough timeline of the recent Equifax scandal:

  • Mid-May 2017 – July 29, 2017: Reported period where Equifax’s systems were breached and data compromised.
  • July 29, 2017: Equifax identified the breach internally.
  • August 1 and August 2, 2017: Executives dumped $1.78 million worth of Equifax stock: Chief Financial Officer, John Gamble ($946,374); U.S. Information Solutions President, Joseph Loughran ($584,099); and Workforce Solutions President, Rodolfo Ploder ($250,458).[2]
  • September 7, 2017: Equifax released a public statement about the breach of over 145 million U.S. consumers’ information, 209,000 credit cards, and other breaches of non-US citizen information.[3]
  • September 12, 2017: Alex Holden, founder of Milwaukee, Wisconsin-based Hold Security LLC, contacted noted cybersecurity reporter, Brian Krebs, on a discovered security flaw within Equifax’s publicly available employee portal in Argentina. The Equifax portal had an active administrative user with the User ID “admin” and the password set to “admin.”  For those of you who may be unaware, the admin/admin username and password combination is regularly used as a vendor default, and often a combination tried by users to break into systems.  The administrative access allowed maintenance of users within the portal, including the ability to show employee passwords in clear-text. [4]
  • September 14, 2017: On his blog, Krebs on Security, Brian Krebs posted an article referencing a non-public announcement Visa and MasterCard sent to banks, which stated that the “window of exposure for the [Equifax] breach was actually November 10, 2016 through July 6, 2017.”[5] (Note: Equifax still claims the breach was one big download of data in Mid-May 2017, and that the November dates were merely transaction dates.)
  • September 15, 2017: Visa and MasterCard updated the breach notification to include social security numbers and addresses. [6] They found that the breach occurred on the Equifax’s site where people signed up for credit monitoring.
  • September 15, 2017: Equifax Chief Information Officer, David Webb, and Chief Security Officer, Susan Mauldin retired, effective immediately.[7][8]
  • September 19, 2017: Equifax admitted they tweeted out a bogus website address at least seven times; for instance, promoting “securityequifax2017.com” instead of the correct site, “equifaxsecurity2017.com,” and thus sent customers to the wrong site. Software engineer Nick Sweeting took the opportunity to teach Equifax a lesson and created an identical site at the incorrect “securityequifax2017.com” with a scathing indictment banner at the top of the page: “Why did Equifax use a domain that’s so easily impersonated by phishing sites?”[9]
  • September 29, 2017: CEO, Richard F. Smith stepped down, though he was expected to walk away with roughly $90 million.[10]
  • September 29, 2017: Astonishingly, the Internal Revenue Service (IRS) awarded Equifax a sole source contract (not publicly bid) for roughly $7.25 million to perform identity verifications for taxpayers.[11] Just in case you were not lucky enough to be a part of the recent Equifax breach, the IRS is giving you another “opportunity.”
  • October 3, 2017: During testimony with House Energy and Commerce Committee, former Equifax CEO, Richard F. Smith, blamed one person in his IT department for not patching the Apache Struts vulnerability and for the entire breach.[12]
  • October 10, 2017: Krebs on Security reported the number of UK Residents hacked was 693,665, not the initial 400,000 disclosed.[13]
  • October 12, 2017: Malicious Adobe Flash code was found on Equifax’s website. Equifax blamed a third-party service provider for feeding the information to the site.
  • October 12, 2017: IRS temporarily suspended Equifax’s contract over additional security concerns.[14]

This is not the first time Equifax has been involved in a breach of customer information.  On September 8, 2017, Forbes released an article detailing prior breaches, including one in May 2016 that leaked personal information of 430,000 records of grocer Kroger’s employees[15]from an Equifax site that provided employees with W2 information.  That breach was attributed to attackers determining PIN numbers utilized for site access to break into accounts and steal information.  PIN numbers consisted of the last four digits of an employee’s social security number and their four-digit birth year.

More information keeps surfacing as Equifax continues to simultaneously be scrutinized for their every move and targeted by security personnel and hackers alike.  A huge question remains how a company managing the information of so many people, who was certified compliant under several different certifications, including PCI DSS, SOC 2 Type II, FISMA, ISO/IEC 27001:2013[16] to name a few, could be so negligent.

From my experience, there are a lot of large corporations out there with the mentality that they are just too big to fail or to comply one-hundred percent.  I have heard echoing of this mantra repeatedly over the years, and every time, it makes you want to scream “you are too big not to comply!”

However, history has proven, a lot of these big corporations are in fact too big to fail.  Sure, Equifax is going to be continuously under scrutiny, fined, sued, and have their name dragged through the mud.  However, at the end of the day, they will still be managing the information for millions of people, not just Americans, and business will continue as usual.  They will be the butt of jokes and the subject of discussion for a while, but then the stories will start to fall behind other major headlines and soon all will be forgotten.

The reality is the Equifax saga is nothing new to consumers, and Equifax joins the likes of Target, Home Depot, Citibank, and many other companies who had their name plastered within headlines for major data breaches.

The compromises made some consumers think twice about using these companies, or using a credit card at their locations, but time moves on and eventually convenience always beats security.  Each of the companies compromised took a financial hit at the time, but years later they are still chugging away, some with record profits.  Sure, the damage made them reorganize and rethink security going forward, but why is it that consumers must suffer first before these large companies take steps to protect them?  While millions of consumers could be facing identity theft or financial compromise due to the Equifax breach, Equifax’s executives cashed out large amounts of stock, took their resignation, and will move on to the next company or retire off their riches.

What is the big picture here?  Is it true what Equifax’s ex-CEO said on the stand, that one member of their information security team caused this huge compromise of data? Of course not, and by the way it was ludicrous for a CEO to place blame on one member of their IT staff.  The truth is companies attempt to juggle their personal profit with the company’s security.  Let’s be honest, most of the time information security spends revenue without a return.  The only time a return is realized is when a company mitigates a breach and that information is not often relayed across an organization.

The damages incurred by consumers and even other businesses due to data breaches far outweigh the penalties the negligent companies face.  The Federal Trade Commission claims that recovering from an identity breach averages six months and 200 hours of work[17].  If only 10% of those involved in the Equifax breach have their identities compromised, using average U.S. hourly earnings, that would equate to roughly $77 billion in potential costs to the American people (14,500,000 people * 200 hours * $26.55 = ~$77 billion).  These are just averages and there are horror stories detailing people fighting for years to clear up their identity.

Overall, there needs to be more accountability and transparency in what these corporations are doing with consumer data.  Most of these companies are going through endless audits covering different regulations and compliances, yet it does not seem to matter, as breaches continue to rise in number.

As other countries are progressively moving forward with reforms for the protection of personal information of their residents, such as the European Union’s General Data Protection Regulation (GDPR), the US continues to blindly stumble along, refusing to take a serious look at these issues.  The amount of money these companies are profiting off the data they collect is ridiculous, and when they have a breach, the fines and other punishments are a joke.

It’s time for things to change, as no company should be able to just say, “whoops, sorry about that” after a breach and move on.

What’s New with the Treacherous 12?

By the CSA Top Threats Working Group

In 2016, the CSA Top Threats Working Group published the Treacherous 12: Top Threats to Cloud Computing, which expounds on 12 categories of security issues that are relevant to cloud environments. The 12 security issues were determined by a survey of 271 respondents.

Following the publication of that document, the group has continued to track the cloud security landscape for incidents. This activity culminated in the creation of an update titled Top Threats to Cloud Computing Plus: Industry Insights.

The update serves as a validation of the relevance of security issues discussed in the earlier document, as well as provides references and overviews of these incidents. In total, 21 anecdotes and examples are featured in the document.

The references and overview of each anecdote and example are written with the help of publicly available information.

The Top Threats Working Group hopes that shedding light on recent anecdotes and examples related to the 12 security issues will provide readers with relevant context that is current and in-line with the security landscape.

 

CSA Releases Minor Update to CCM, CAIQ

By the CSA Research Team

The Cloud Security Alliance has released a minor update for the Cloud Control Matrix (CCM) and the Consensus Assessment Initiative Questionnaire (CAIQ) v3.0.1. This update incorporates mappings to Shared Assessments 2017 Agreed Upon Procedures (AUP), PCI DSS v3.2, CIS-AWS-Foundation v1.1, HITRUST CSF v8.1, NZISM v2.5.

The Cloud Security Alliance would like to thank the following individuals and organizations for their contributions to this minor update of the CCM.

Shared Assessments 2017 AUP
Angela Dogan
The Shared Assessments Team

PCI DSS v3.2 
Michael Fasere
Capital One

NZISM v2.5
Phillip Cutforth
New Zealand Government CIO

HITRUST CSF v8.1
CSA CCM Working Group

CIS-AWS-Foundations
Jon-Michael Brook

Learn more about this minor update to the CCM. Please feel free to contact us at [email protected]nce.org if you have any queries regarding the update.

If you are interested in participating in future CCM Working Group activities, please feel free to sign up for the working group.

The GDPR and Personal Data…HELP!

By Chris Lippert, Senior Associate, Schellman & Co.

With the General Data Protection Regulation (GDPR) becoming effective May 25, 2018, organizations (or rather, organisations) seem to be stressing a bit. Most we speak with are asking, “where do we even start?” or “what is included as personal data under the GDPR?” It is safe to say that these are exactly the questions organizations should be asking, but to know where to start, organizations first need to understand how the GDPR applies to their organization within this new definition for personal data. Without first understanding what to look for, an organization cannot begin to perform data discovery and data mapping exercises, review data management practices and prepare the organization for compliance with the GDPR.

Personal data redefined…sort of.
To start – is personal data redefined by the GDPR? Yes. Is it more encompassing of a definition? Yes. Does it provide a good amount of guidance on interpretation of said definition? In some areas, but not in others.

The Articles of the GDPR open with a list of definitions in Article 4 that provide some guidance on how to digest the remainder of the regulation—the recitals also contain some nuggets of wisdom if you have time to review. Personal data is the very first definition listed under Article 4, hinting that it is most likely pertinent to a comprehensive understanding of the regulation. Article 4(1) states:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

In breaking down this definition, there are a few key phrases to focus on. Any information is the big one, as it confirms that personal data, under this regulation, is not limited to a particular group or type of data. Relating to specifies that personal data can encompass any group or type of data, as long as the data is tied to or related to something else. What is that something else? A natural person. A natural person is just that—an actual human being to whom the data applies.

You may have noticed I skipped the ‘an identified or identifiable’ portion of the definition—identified or identifiable means that the natural person has either already been identified, or can readily be identified utilizing other available information. Article 4(1) adds further clarity here, stating that an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. The fact that name, identification number, location data and online identifier are specifically referenced at the beginning of this definition is important, as those pieces of data serve to directly identify an individual. If that specific data is held by the organization, all related data is in scope.

However, if those unique identifiers are not held, your organization should reference the list of other data that could otherwise identify the natural person and bring everything into scope. For example, you may not have John Smith’s name in your database, but you may have salary, company name, and city that that point directly to John Smith when linked together.

In addition to the new definition of personal data, the GDPR also adds some more specificity around what it deems “special categories” of personal data. Article 9 1. states:

processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.

This definition is important, as this states that certain personal data falls into a subcategory that has stricter processing requirements. Although the requirement above states that processing of special categories of personal data is prohibited, it is important to note that there are exceptions to this rule. Organizations should reference Article 9 if they believe special categories of data to be in scope.

So how does this definition differ from previous definitions of personal data?
Even though the GDPR “redefines” personal data, is it really all that different from existing definitions? As a baseline, let’s refer to two of the more commonly used definitions for personal data taken from the GDPR’s predecessor—the Data Protection Directive—and NIST 800-122.

The Data Protection Directive defines personal data in Article 2 (a), which states ‘personal data ‘ shall mean any information relating to an identified or identifiable natural person (‘data subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity. This definition is almost identical to that of the GDPR. The main difference is that the GDPR added additional data that can identify an individual, such as name, location data and online identifier. By adding these into the mix, the GDPR is clarifying where individuals are presumed to be identified, helping organizations understand that the data associated with those identifiers is in scope and covered under the regulation.

Special categories of personal data is also defined under the Data Protection Directive. Article 8 1. states Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. The GDPR expanded on this definition as well, now including genetic and biometric data, as well as sexual orientation data to be included in special categories. Essentially, the GDPR has taken the definitions for both personal data and special categories from the Data Protection Directive and provided more clarity, while making them more inclusive at the same time.

Most people probably expect the Data Protection Directive and GDPR to have similar definitions, as they are essentially version 1 and 2 of modern day EU data privacy legislation, respectively. However, when compared to the definition of personal data contained in U.S.-based guidance, we start to see some key differences. As the National Institute of Standards and Technology (NIST) is widely accepted, let’s look at their definition of personal data found in their Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) from 2010.  NIST 800-122, Section 2.1 states PII is – any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

In breaking down this NIST definition, we see some similarities, in that the NIST definition starts off just as broadly with the phrasing “any information.” In the same vein, the wording “about an individual” speaks to the clarification provided in the GDPR definition as well. That being said, the definition then goes on to add more specifics regarding information that can identify or be linked to an individual, which is where we start to notice some differences. The identifying pieces of information listed in the NIST definition includes name, social security number, date and place of birth, mother’s maiden name or biometric records. The GDPR is a bit more inclusive in its definition, including name, identification number, location data, and online identifier, which covers most of the items from the NIST definition but also adds the online portion as well. While the GDPR doesn’t include the biometric data in the main definition, it does cover physical and genetic information in the other related information listing.

These differences don’t stop there. The NIST definition does go on to provide guidance on other information that could be linked to the individual, but instead of listing out specific data, the definition focuses rather on sectoral categories of data that seem to be derived from the sectoral privacy laws in the United States. The GDPR definition does not follow this pattern, and instead focuses on the different data that can be linked to an individual from a more generic standpoint, listing out the pieces of information that could be tied to an individual in most industries. Also, while the GDPR definition states that one or more of those other data elements can also identify the individual, the NIST definition really brings that other information into scope by saying it can be personal data as long as the individual is identified—though it does not state that the information can also be used to identify an otherwise unidentified individual.

Final Thoughts
With the GDPR’s becoming effective next year, it’s clear that this new definition of personal data expands on the preexisting EU definition of personal data contained in the Data Protection Directive.  Additionally, it adds more specificity to the data that can be used to identify an individual in comparison with leading US personal data definitions.

Why is this so important and relevant to organizations? This new definition of personal data is the most comprehensive definition to date, bringing into scope more information to be considered than any previous definitions in industry regulations or standards. Now, organizations will need to take another look at their previous determination of personal data and reevaluate their data management practices to ensure that the information they hold has been labeled and handled correctly. In fact, information deemed not applicable to past privacy regulations and standards may now become relevant when taking the new definition of personal data into consideration.

Look no further than IP addresses.  Most companies wouldn’t normally lump in IP addresses with personal data, but the now-effective GDPR specifically calls out online identifiers in the definition of personal data. The Court of Justice for the European Union (CJEU) issued its judgement indicating as such in Case C-582/14: Patrick Breyer v Bundesrepublik Deutschland, setting precedent that even dynamic IP addresses can be considered personal data in certain situations. Given this new standard, it will be important for organizations to incorporate judgements from recent cases and guidance from the Article 29 Working Party (being replaced by the European Data Protection Board in May of 2018) when determining how the GDPR impacts to their organization and how best to comply.

New procedures and criteria can be confusing, but hopefully the information above has provided some clarity around this new definition of personal data that the GDPR will introduce next year. Basic knowledge of these definitions can be a starting point for determining how the GDPR applies to your organization, and  if approached from a comprehensive data and risk management standpoint, this information can help better prepare your organization for compliance with the GDPR and other future privacy regulations and frameworks.

If you should have any questions regarding the new definition of personal data or the GDPR in general, please feel free to reach out to your friendly neighborhood privacy team here at Schellman.

Webinar: How Threat Intelligence Sharing Can Help You Stay Ahead of Attacks

By Lianna Catino, Communications Manager, TruSTAR Technology

According to a recent Ponemon Institute survey of more than 1,000 security practitioners, 84 percent say threat intelligence is “essential to a strong security posture,” but the data is too voluminous and complex to be actionable.

Enter the CloudCISC Working Group. Powered by TruSTAR’s threat intelligence platform, more than 30 CSA enterprise members are now actively exchanging threat data on a daily basis to help them surface relevant intelligence. The platform allows security analysts to mine historical incident data correlations among CSA members to take faster action against new threats.

This month CloudCISC marks its one year anniversary, and to celebrate we’re bringing you a recap of some of the hottest trending threats we’re seeing on the CSA platform in Q3.

Led by CSA and TruSTAR, we’ll be walking you through the CloudCISC platform and dissecting threats that are specifically relevant and trending among CSA members.

In the event you missed it, you can watch the replay.

Thinking of joining CSA’s Cloud Cyber Intelligence Exchange? Request your invitation today.

Improving Metrics in Cyber Resiliency: A Study from CSA

By  Dr. Senthil Arul, Lead Author, Improving Metrics in Cyber Resiliency

With the growth in cloud computing, businesses rely on the network to access information about operational assets being stored away from the local server. Decoupling information assets from other operational assets could result in poor operational resiliency if the cloud is compromised. Therefore, to keep the operational resiliency unaffected, it is essential to bolster information asset resiliency in the cloud.

To study the resiliency of cloud computing, the CSA formed a research team consisting of members from both private and public sectors within the Incident Management and Forensics Working Group and the Cloud Cyber Incident Sharing Center.

To measure cyber resiliency, the team leveraged a model developed to measure the resiliency of a community after an earthquake. Expanding this model to cybersecurity introduced two new variables that could be used to improve cyber resiliency.

  • Elapsed Time to Identify Failure (ETIF)
  • Elapsed Time to Identify Threat (ETIT)

Measuring these and developing processes to lower the values of ETIF and ETIT can improve the resiliency of an information system.

The study also looked at recent cyberattacks and measured ETIF for each of the attacks. The result showed that the forensic analysis process is not standard across all industries and, as such, the data in the public domain are not comparable. Therefore, to improve cyber resiliency, the team recommends that the calculation and publication of ETIF be transferred to an independent body (such as companies in IDS space) from the companies that experienced cyberattacks. A technical framework and appropriate regulatory framework need to be created to enable the measurement and reporting of ETIF and ETIT.

Download the full study.