Weigh in on the Cloud Control Matrix Addenda

Mapping of the cloud controls matrixDear Colleagues,

The Cloud Security Alliance would like to invite you to review and comment on the Cloud Control Matrix (CCM) addenda for the following standards:

—German Federal Office for Information Security (BSI) Cloud Computing Compliance Controls Catalogue (C5). (Add your comments to CCM-C5.)
—ISO/IEC 27002, ISO/IEC 27017 and ISO/IEC 27018. (Add your comments to CCM-ISO.)

These CCM addenda aim to help organizations assess and bridge compliance gaps between the CCM and other security frameworks. The documents contain:

  • a controls mapping between the above mentioned standards and the CCM (e.g., which control(s) in CCM maps to each given control in ISO27017),
  • a gap analysis, and
  • compensating controls (i.e. the actual “addendum”).

The CSA and the CCM Working Group hope that organizations will find this document useful for their security compliance programs.

To participate, please follow the links above to the review site. From there, you should be able to navigate to Google Sheets and provide your comments. Please do not provide editorial comments (i.e. grammar, formatting, etc), rather focus instead on the content of the document.

The peer review ends on December 20, 2018. We appreciate your assistance and thank you in advance for your time and contributions.

Best Regards,
CSA Research Team

CCSK Success Stories: Cloud Security Training from a CTO’s Perspective

By the CSA Education Team

Cory Cowgill headshotWe’re kicking off a series on cloud security training today with a Q&A with the Vice President and CTO of Fusion Risk Management, Cory Cowgill. With a background in enterprise software development spanning multiple industries, Cowgill has multiple certifications including Salesforce System Architect and Application Architect, Amazon Web Services Solution Architect, and Cloud Security Alliance Certificate of Cloud Security Knowledge (CCSK). He has presented at Dreamforce, the world’s largest enterprise software conference eight times, and is a member of the Salesforce MVP Hall of Fame.

What led you to the Certificate of Cloud Security Knowledge?

The research and work with the CCM (Cloud Controls Matrix) led me to the CSA Certificate of Cloud Security Knowledge. I am a lifelong learner so I decided to take the exam. I recently passed the CSA Certificate of Cloud Security Knowledge, and I found so much of the content directly valuable. I would recommend it to all IT security professionals. It provides a set of comprehensive and vendor-neutral cloud computing principles that are invaluable across security roles and responsibilities. The CSA Security Guidance v4 document will be required reading for all my engineering talent in our organization going forward.

You said you found so much of the CCSK content “directly valuable.” Could you talk more about the specific content you were able to use in your job?

Sure. As a CTO of a SaaS company, I am often engaged in prospect and customer discussion around our products security posture. I have found all of the domains to be helpful, but I find two domains especially helpful based on where a customer is on their cloud journey. Domain 1, “Cloud Computing Concepts and Architectures” is especially helpful when establishing a conversation with a customer who is very early on their journey, helping establish what the shared responsibility model will look like. For customers who are well on their cloud journey, I find Domain 6, “Management Plane and Business Continuity” to be extremely helpful as the management plane is where they customer will be implementing the majority of their security controls under the shared responsibility model.

What’s the value in a vendor-neutral certificate like the CCSK or CCSP versus getting certified by AWS? In what scenario are the different certificates important?

The CCSK or CCSP provide the most value to individuals who may need to work with an array of cloud vendors. Many organizations have a mix of CSPs who provide a range of SaaS and IaaS solutions. Individuals responsible for the overall security posture of the organization cannot be expected to hold a certification for each CSP’s technology stack. This is where the CCSK or CCSP become valuable as you have a credential that is relevant to assessing the overall security posture regardless of vendor specific technical details. Vendor certifications are valuable to those individuals in the organization who are configuring and administering those specific CSP solutions.

What’s a common problem you see organizations struggling with when migrating to the cloud?

As the CTO I am frequently engaged in discussions with customers and prospects around the security posture of our SaaS product. It is no small understatement to say that there is a lot of education that needs to be done within enterprise IT security teams. Companies struggle to ask the right questions around cloud security as many still do not fundamentally understand the benefits of the cloud. Each organization has a separate set of questions or controls they want to discuss which takes considerable effort from both internal IT security resources and SaaS provider security teams.

This led me to the Cloud Security Alliance (CSA) and the Cloud Controls Matrix (CCM). The CCM addresses these pain points by providing a standardized controls matrix that can be used to drive the discussion between cloud vendors and cloud customers.

How did CCM help communicate with customers?

By providing our standard CCM to prospects and customers along with our other compliance certifications and security assets we can rapidly assure customers and prospects that we are “Protecting the covenant of trust.”

When you said, “companies struggle to ask the right questions around cloud.” What types of questions are companies asking that they shouldn’t be asking? What types of questions do they need to be asking?

Many of the questions I respond to are very granular, infrastructure-related questions phrased or worded in terminology that is very specific to on-premise services. I seldom get asked about the management plane and the security controls and capabilities that fall under the responsibility of a customer in the shared responsibility model. The major CSPs have extremely mature security controls with compliance, certifications, and other attestations around their infrastructure components. While important to review that material and understand the infrastructure controls, the greatest risk is misconfiguration of the cloud services by the customer. Therefore, customers and prospects would be better served by understanding the management plane and security controls that are their responsibility to configure. This applies to all service models whether SaaS, PaaS, or IaaS.

While important to review that material and understand the infrastructure controls, the greatest risk is misconfiguration of the cloud services by the customer.

Some people are unfamiliar with the CSA Security Guidance. What would you compare it to?

All of the major cloud vendors across the service models have detailed documentation and guidance on their security postures and available controls. However, most enterprises have multiple cloud service providers with different delivery models and what is missing is a way to establish a common dialog across these CSPs’ security capabilities. In this regard I would compare the CSA security guidance to a critical guidebook that helps you establish a common dialog across CSPs as you evaluate their security postures.

What’s the biggest hurdle for security professionals who aren’t familiar with the cloud yet?

I think the biggest challenge is that there are so many different cloud technologies which can cause analysis paralysis. Do I get started with IaaS? If so do I pursue AWS, Azure, or Google? Do I start with a huge SaaS / PaaS vendor like Salesforce or ServiceNow? What will be most relevant? And when you couple this large array of CSPs with continually evolving technologies like serverless, it can be overwhelming to many. My advice is you can’t go wrong with any one vendor. You kind of need to just dive in the pool so to speak. Keep up the great work CSA!

If you’re interested in learning more about cloud security training for you or your team, please visit our CCSK Training page.

Invest in your future with CCSK training

 

Cory Cowgill headshotCory Cowgill is the Vice President & Chief Technology Officer, Fusion Risk Management, Inc., where he is responsible for research and development, customer engagement, operations and security, and go-to market initiatives. With a background in enterprise software development spanning multiple industries, Cowgill leads with a dedication to technology and risk management.

AWS Cloud: Proactive Security and Forensic Readiness – Part 4

Part 4: Detective Controls in AWS

By Neha Thethi, Information Security Analyst, BH Consulting

Security controls can be either technical or administrative. A layered security approach to protecting an organization’s information assets and infrastructure should include preventative controls, detective controls and corrective controls.

Preventative controls exist to prevent the threat from coming in contact with the weakness. Detective controls exist to identify that the threat has landed in our systems. Corrective controls exist to mitigate or lessen the effects of the threat being manifested.

This post relates to detective controls within AWS Cloud. It’s the fourth in a five-part series that provides a checklist for proactive security and forensic readiness in the AWS Cloud environment.

Detective controls in AWS Cloud

AWS detective controls include processing of logs and monitoring of events that allow for auditing, automated analysis, and alarming.

These controls can be implemented using AWS CloudTrail logs to record AWS API calls, Service-specific logs (for Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc) and AWS Config to maintain a detailed inventory of AWS resources and configuration. Amazon CloudWatch is a monitoring service for AWS resources and can be used to trigger CloudWatch events to automate security responses. Another useful tool is Amazon GuardDuty which is a managed threat detection service in AWS and continuously monitors for malicious or unauthorized.

Event logging

Security event logging is crucial for detecting security threats or incidents. Security teams should produce, keep and regularly review event logs that record user activities, exceptions, faults and information security events. They should collect logs centrally and automatically analysed to detect suspicious behavior. Automated alerts can monitor key metrics and events related to security. It is critical to analyse logs in a timely manner to identify and respond to potential security incidents. In addition, logs are indispensable for forensic investigations.

The challenge of managing logs

However, managing logs can be a challenge. AWS makes log management easier to implement by providing the ability to define a data-retention lifecycle or define where data will be preserved, archived, or eventually deleted. This makes predictable and reliable data handling simpler and more cost-effective.

The following list recommends use of AWS Trusted Advisor for detecting security threats within the AWS environment. It covers collection, aggregation, analysis, monitoring and retention of logs, and, monitoring security events and billing to detect unusual activity.

The checklist provides best practice for the following:

  1. Are you using Trusted Advisor?
  2. How are you capturing and storing logs?
  3. How are you analyzing logs?
  4. How are you retaining logs?
  5. How are you receiving notification and alerts?
  6. How are you monitoring billing in your AWS account(s)?

Best-practice checklist

1. Are you using Trusted Advisor?
  • Use AWS Trusted Advisor to check for security compliance.
    Back to List
2. How are you capturing and storing logs?
  • Activate AWS Cloud Trail.
  • Collect logs from various locations/services including AWS APIs and user-related logs (e.g. AWS CloudTrail), AWS service-specific logs (e.g. Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc.), operating system-generated logs, IDS/IPS logs and third-party application-specific logs
  • Use services and features such as AWS CloudFormation, AWS OpsWorks, or Amazon Elastic Compute Cloud (EC2) user data, to ensure that instances have agents installed for log collection
  • Move logs periodically from the source either directly into a log processing system (e.g., CloudWatch Logs) or stored in an Amazon S3 bucket for later processing based on business needs.Back to List
3. How are you analyzing logs?
  • ​​Parse and analyse security data using solutions such as AWS Config, AWS CloudWatch, Amazon EMR, Amazon Elasticsearch Service, etc.
  • Perform analysis and visualization with Kibana.
    Back to List
4. How are you retaining logs?
  • Store data centrally using Amazon S3, and, for long-term archiving if required, using Amazon Glacier
  • Define data-retention lifecycle for logs. By default, CloudWatch logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a retention period between 10 years and one day
  • Manage log retention automatically using AWS Lambda.
    Back to List
5. How are you receiving notification and alerts?
  • ​​Use Amazon CloudWatch Events for routing events of interest and information reflecting potentially unwanted changes into a proper workflow
  • Use Amazon GuardDuty to continuously monitor for malicious or unauthorized behavior
  • Send events to targets like an AWS Lambda function, Amazon SNS, or other targets for alerts and notifications.
    Back to List
6. How are you monitoring billing in your AWS account(s)?
  • Use detailed billing to monitor your monthly usage regularly
  • Use consolidated billing for multiple accounts. Back to List

Refer to the following AWS resources for more details:

Next up in the blog series, is Part 5 – Incident Response in AWS – best practice checklist. Stay tuned. Let us know in the comments below 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.

Data Breaches on the Rise in Financial Services

By Jacob Serpa, Product Marketing Manager, Bitglass

Financial World: Breach Kingdom report coverFinancial services organizations are a prime target for hackers looking to steal and sell valuable data. This is because these firms handle sensitive information known as PII, personally identifiable information, as well as other financial data. In Financial World: Breach Kingdom, Bitglass’ latest financial breach report, the Next-Gen CASB reveals information about the state of security for financial services in 2018. Read on to learn more.

The rise of financial services breaches

2018 has seen the number of financial services breaches reach new heights. This is likely due to a large number of reasons. For example, some organizations may have an overreliance upon existing cybersecurity infrastructure and find it difficult to justify additional expenses in light of their existing sunk costs in security. Other firms may simply overestimate what traditional endpoint and premises-based tools can do to protect data from evolving threats. Regardless, the fact remains that financial services firms were breached in 2018 nearly three times more than they were in Bitglass’ previous, 2016 report.

Malware leads the pack

In prior years, the causes of financial services breaches were fairly diverse. Lost or stolen devices and hacking each caused about 20 percent of breaches, while unintended disclosures and malicious insiders were responsible for 14 percent and 13 percent, respectively.

However, this year saw a massive shift in the balance of power. Nearly three quarters of all financial services breaches in 2018 were caused by malware or hacking. This seems consistent with headlines over the last year – ransomware, cloud cryptojacking, and highly specialized malware variants have dominated the news when it comes to breaches.

What to do?

In financial services, far more must be done to secure sensitive information. While it is imperative that the enterprise can protect data against any threat, it is now clear that defending against malware deserves special attention. This is particularly true in light of the rise of cloud and BYOD. More devices and applications are storing and processing data than ever before, creating more opportunities for malware to infect the enterprise. Fortunately, there are appropriate solutions available.

To learn more about the state of cybersecurity in financial services, download Financial World: Breach Kingdom.

Cloud Security Alliance Releases Minor Update to CCM v3.0.1

By the CSA Research Team

CCM logoThe Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) Working Group has released a minor update for the CCM v3.0.1. This update incorporates mappings to IEC 62443-3-3 and BSI Compliance Controls Catalogue (C5).

The CCM is specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains. The foundations of the Cloud Security Alliance Controls Matrix rest on its customized relationship to other industry-accepted security standards, regulations, and controls frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP and will augment or provide internal control direction for service organization control reports attestations provided by cloud providers.

As a framework, the CSA CCM provides organizations with the needed structure, detail and clarity relating to information security tailored to the cloud industry. It strengthens existing information security control environments by emphasizing business information security control requirements, reduces and identifies consistent security threats and vulnerabilities in the cloud, provides standardized security and operational risk management, and seeks to normalize security expectations, cloud taxonomy and terminology, and security measures implemented in the cloud.

The CSA CCM Working Group would like to thank the following individuals for their contributions to this minor update:

Siemens

  • Claus Matzke
  • Kristian Beckers

CCM Working Group

  • Noel Haskins-Hafer
  • Kris Seeburn
  • Amita Radhakrishnan
  • Angela Dogan
  • Dibya Ranjan Nath
  • Hardeep Mehrotara
  • Jevon Wooden
  • Keith Stocks
  • Leena Singal
  • Loredana Mancini
  • Manjunath A.T.
  • Michael Roza
  • Reid Leake
  • Subrata Baguli
  • Umar Khan
  • Vamsi Kaipa

Please feel free to contact us at [email protected] 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.

Cloud Security Alliance Announces the Release of the Spanish Translation of Guidance 4.0

By JR Santos, Executive Vice President of Research, Cloud Security Alliance.

Guidance 4.0 Spanish version coverThe Cloud Security Alliance (CSA), the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment, today announced the release of Guidance for Critical Areas of Focus in Cloud Computing 4.0 in Spanish. This is the second major translation release since Guidance 4.0 was released in July of 2017 (Previous version was released in 2011).

An actionable cloud adoption roadmap

Guidance 4.0, which acts as a practical, actionable roadmap for individuals and organizations looking to safely and securely adopt the cloud paradigm, includes significant content updates to address leading-edge cloud security practices.

Approximately 80 percent of the Guidance was rewritten from the ground up with domains restructured to better represent the current state and future of cloud computing security. Guidance 4.0 incorporates more of the various applications used in the security environment today to better reflect real-world security practices.

“Guidance 4.0 is the culmination of more than a year of dedicated research and public participation from the CSA community, working groups and the public at large,” said Rich Mogull, Founder & VP of Product, DisruptOPS. “The landscape has changed dramatically since 2011, and we felt the timing was right to make the changes we did. We worked hard with the community to ensure that the Guidance was not only updated to reflect the latest cloud security practices, but to ensure it provides practical, actionable advice along with the background material to support the CSA’s recommendations. We’re extremely proud of the work that went into this and the contributions of everyone involved.”

CCM, CAIQ, DevOps and more

Guidance 4.0 integrates the latest CSA research projects, such as the Cloud Controls Matrix (CCM) and the Consensus Assessments Initiative Questionnaire (CAIQ), and covers such topics as DevOps, IoT, Mobile and Big Data. Among the other topics covered are:

  • DevOps, continuous delivery, and secure software development;
  • Software Defined Networks, the Software Defined Perimeter and cloud network security.
  • Microservices and containers;
  • New regulatory guidance and evolving roles of audits and compliance inheritance;
  • Using CSA tools such as the CCM, CAIQ, and STAR Registry to inform cloud risk decisions;
  • Securing the cloud management plane;
  • More practical guidance for hybrid cloud;
  • Compute security guidance for containers and serverless, plus updates to managing virtual machine security; and
  • The use of immutable, serverless, and “new” cloud architectures.

The oversight of the development of Guidance 4.0 was conducted by the professional research analysts at Securosis and based on an open research model relying on community contributions and feedback during all phases of the project. The entire history of contributions and research development is available online for complete transparency.

Seven Reasons Why Proxy-based CASBs Are Required for Office 365

By Rich Campagna, Chief Marketing Officer, Bitglass

O365 logoA competing CASB vendor blogged recently on why proxy-based Cloud Access Security Brokers (CASBs) shouldn’t be used for Office 365.

The post cites “7 reasons,” all of which are variations of just one reason: their CASB breaks each time Microsoft makes changes to Office 365.  What they call “application breakages” due to “updates,” are really “CASB outages.”  In other words, dog ate their homework.

A commonly cited issue with proxies (the only way to achieve real-time cloud data loss prevention or DLP) is their ability to adjust to the near constant changes in cloud applications. However, without an automated solution that can respond to these changes in real time, it’s up to quick response by CASB engineers to fix breakages after they occur, which leads to inevitability of downtime. Make sure you don’t fall into this trap. Select a CASB that can adapt to changes on the fly. Don’t throw out proxy technology completely just because some vendors can’t do it properly.

Proxy-based CASBs: Seven reasons why

So, knowing that a proxy-based solution for Office 365 can work, if you pick the right one, why go inline with Office 365 versus relying purely on out-of-band API integration? Here are 7 unique reasons:

  1. Managed vs Unmanaged Device Access Control – For most organizations, a managed device represents a much lower risk than an unmanaged BYO device. Proxy-based controls allow you to distinguish between the two and provide a different level of access to the app and to sensitive corporate data.
  2. OneDrive Sync Client Control – A OneDrive sync client constantly synching many GBs of corporate data to an unmanaged device is riskier than a user on that device logging into OneDrive via web browser to download a couple of files that they need. Proxy allows you to control by access method,
  3. Real-time Data Leakage Prevention – API-based integration with apps like Office 365 is great for scanning data-at-rest, but only provides “Monday morning” notifications of data leakage. Proxies prevent data leakage in real-time.
  4. BYOD Malware Prevention – Your organization probably has unmanaged devices connecting into Office 365. Devices that could be infected with malware. Proxy-based solutions stop malware from making its way into Office 365, thwarting would-be attempts to use Office as an IT sanctioned and paid for malware distribution tool.
  5. Session Management – You likely want to aggressively time out and reauthenticate users on unmanaged or new devices. Possible with proxy, not possible with API.
  6. Step-up Multifactor Authentication – See suspicious activity mid-session? Evidence of credential compromise? Only inline CASB allows you to do something about it as it starts to occur.
  7. Data-at-rest Encryption – In many industries, there is a desire to use the public cloud but without giving up control over your data. Proxy-based CASBs allow you to encrypt data before it gets to the cloud. Public cloud apps with private cloud security – have your cake and eat it too!

Bonus: One bonus add — Office 365 might be your main (or only) cloud app today, but that will most definitely change in the future. The fact is, only a small handful of cloud applications provide APIs that are security relevant, whereas a properly architected proxy can support any application.

Bitglass Security Spotlight: Uber, Apollo, & Chegg

By Jacob Serpa, Product Manager, Bitglass

man reading cybersecurity stories in newspaperHere are the top cybersecurity stories of recent weeks:

—Uber fined $148 million over cover-up
—Apollo database of 200 million contacts breached
—Chegg hack exposes 40 million users’ credentials
—Port of San Diego faces cyberattack

Uber fined $148 million over cover-up

In late 2016, Uber suffered a breach at the hands of hackers who were looking to infiltrate one of the company’s cloud services. However, instead of reporting the event (as they were supposed to), they instead paid the culprits $100,000 and elected to keep silent about the attack. Since then, all fifty states, as well as the District of Colombia, have sought legal action against the company, culminating in a fine of $148 million.

Apollo database of 200 million contacts breached

Apollo, a well-known sales engagement startup, recently had its database of 200 million contacts breached by malicious parties. Unfortunately, as detailed in the message that the company sent to the individuals whose information was exposed, the breach did take a number of weeks to detect. As massive damage can be done in a matter of moments, organizations must employ real-time security measures if they want to avoid a similar fate.

Chegg hack exposes 40 million users’ credentials

Chegg was recently found to have been breached by unauthorized users seeking to steal sensitive information. While it is believed that no Social Security numbers were stolen, data that was successfully exfiltrated included users’ names, usernames, passwords, email addresses, shipping addresses, and more. Unfortunately, the breach, which occurred in April of 2018, took months to detect, giving hackers plenty of time to pursue their malicious ends. The company has since reset the affected users’ passwords.

Port of San Diego faces cyberattack

Within a week of the cyberattack on the Port of Barcelona in Spain, another assault was launched upon the Port of San Diego. This pair of cyberattacks highlights the reality that hackers can target infrastructure and have widespread, adverse repercussions for organizations around the world. Fortunately, this particular attack affected only land-based operations at the port. The causes have yet to be discovered.

Learn about cloud access security brokers (CASBs) and how they can protect your enterprise from threats in the cloud and download the Definitive Guide to CASBs.

Bitglass Security Spotlight: Veeam, Mongo Lock, Password Theft, Atlas Quantum & the 2020 Census

By Jacob Serpa, Product Manager, Bitglass

man reading cybersecurity headlinesHere are the top cybersecurity headlines of recent weeks:
—440 million email addresses exposed by Veeam
—Unprotected MongoDB databases being targeted
—42 million emails, passwords, and more leaked
—Cold-boot attacks steal passwords and encryption keys
—2 billion devices still vulnerable to Bluetooth attack
—Atlas Quantum, cryptocurrency platform, breached
—Security concerns around the 2020 census
—Air Canada’s mobile app breached
—WellCare breach exposes data of 20k children

440 million email addresses exposed by Veeam

Data management company Veeam has ironically mismanaged hundreds of millions of users’ data. A public-facing database exposed 440 million users’ email addresses, names, and, in some circumstances, IP addresses. While this leak may seem innocuous, names and email addresses are all that is needed to conduct targeted spear phishing attacks.

Unprotected MongoDB databases being targeted

The rise of the Mongo Lock attack is seeing improperly secured, poorly configured Mongo DB databases being targeted in a ransomware-like fashion. In these attacks, hackers scan for publicly accessible databases, remove their contents, and demand a Bitcoin ransom in exchange for having data returned.

42 million emails, passwords, and more leaked

A public hosting service that allows individuals to upload files for free was recently found to contain a massive amount of personal data. Over 42 million email addresses and passwords, as well as partial credit card numbers, were found within the platform. As noted in the Veeam section, hackers can easily use this type of data to conduct targeted spear phishing campaigns and steal more sensitive information.

Cold-boot attacks steal passwords and encryption keys

A new cold-boot attack can take information in under two minutes from unsuspecting victims. The attack, which is further detailed at the above link, involves stealing information from RAM, or random access memory. Through this tactic, passwords and even encryption keys can be stolen. Fortunately, hackers need physical access to a computer to execute this kind of technique. Rather than allowing a system to sleep, forcing it to hibernate or shut down is a helpful defense.

2 billion devices still vulnerable to Bluetooth attack

One year ago, BlueBorne, a collection of vulnerabilities in devices that leverage Bluetooth, was revealed. Unfortunately, despite the fact that an entire year has gone by, 2 billion devices remain exposed. This is due to systems that have not been patched, systems that cannot be patched, and more.

Atlas Quantum, cryptocurrency platform, breached

Well-known cryptocurrency platform Atlas Quantum was recently found to have been breached. 261,000 of the company’s users had their names, account balances, email addresses, and phone numbers exposed. While the company initially declined to disclose the circumstances surrounding the breach, it did state that users’ cryptocurrencies were safe – it was merely information that was stolen.

Security concerns around the 2020 census

In the US, the Government Accountability Office has concerns about the cybersecurity of the Census Bureau. The bureau is reported to have thousands of security vulnerabilities – dozens of which are identified as highly risky and dangerous. Naturally, as conducting a census involves collecting data from countless citizens, these security gaps must be filled before the next census in 2020.

Air Canada’s mobile app breached

Late last month, Air Canada’s mobile app was found to have been breached. While it was only 1% of the application’s 1.7 million users that were affected, it was still 20,000 individuals who had their names, phone numbers, passport numbers, and dates of birth exposed.

WellCare breach exposes data of 20k children

In WellCare Health Plans’ recent breach, 20,000 children had their PHI (protected health information) exposed. The information’s security was compromised when WellCare accidentally mailed letters to the wrong addresses. Exposed data included children’s names, ages, and healthcare providers.

Learn about cloud access security brokers (CASBs) and how they can defend against the rising tide of data breaches.

 

POC the CASB

By Rich Campagna, Chief Marketing Officer, Bitglass

POCtheCASB poster imageThe Cloud Access Security Broker, or CASB, space has quickly made its way to the mainstream, with organizations of every size and every industry deploying CASBs whenever their data moves beyond the firewall.

While ready for primetime and widely deployed, some enterprises are taking the risky step of skipping the proof-of-concept or trial phase. Given the rapid evolution of the enterprise use cases, and of CASB vendor solutions, we always encourage organizations to #POCtheCASB (of course, it helps that our sales team has complete confidence in the quality of our CASB solution and in our support …).

Seven ways to #POCtheCASB

Here are a few of the key areas to focus on for a successful trial:

  • Proxy Robustness – A commonly cited issue with proxies (the only way to achieve real-time cloud data loss prevention or DLP) is their ability to adjust to the near constant changes in cloud applications. However, without an automated solution that can respond to these changes in real time, it’s up to quick response by CASB engineers to fix breakages after they occur, which leads to inevitability of downtime. Make sure you don’t fall into this trap. Select a CASB that can adapt to changes on the fly. Don’t throw out proxy technology completely just because some vendors can’t do it properly.
  • User Experience – The days of the security team being able to put their needs ahead of the user experience are long gone. Be sure to test with volunteer users from a variety of different business units or departments. Ensure that the CASB solution preserves the user experience and requires minimal or no retraining for your test group.
  • Managed and Unmanaged Device Access – Even if you held BYOD at bay with premises applications, it will become a reality when you move to the cloud. Be sure to test the capabilities of the CASB on both managed devices, as well as on a range of BYO device types to ensure that policy and control capabilities work equally well on all device types.
  • Performance – A well-architected CASB solution should offer high performance and low latency for all users globally, as well as when under peak load. Test from a variety of geos and from several different times of day.
  • Enterprise Integration – Most enterprises end up integrating their CASB into several other systems including Active Directory, IDaaS, network DLP, SIEM and more. Test to be sure that the CASB has appropriate connectors for each of these systems.
  • Flexibility – You might initially deploy a CASB for a small number of cloud applications, but for most enterprises, their cloud footprint begins to evolve and grow rapidly once cloud takes root in the organization. Ensure that you develop test cases that exercise the CASBs ability to test not only your current needs, but the future needs of your business.
  • Policy – Last but not least, test out the policies you plan to develop on your CASB! Whether you’re planning to use baseline policies like access control and UEBA, or more sophisticated policies involving DLP and encryption, run the test CASB(s) through their policy paces.

Bitglass Security Spotlight: Yale, LifeLock, SingHealth, Malware Evolving & Reddit Breached

By Jacob Serpa, Product Manager, Bitglass

man reading cybersecurity headlinesHere are the top cybersecurity headlines of recent months:

—Future malware to recognize victims’ faces
—Reddit suffers breach
—6 million records of Georgian voters exposed
—RASPITE Group attacks US infrastructure
—Decade-old breach at Yale uncovered
—Bug exposes LifeLock customer data
—Patient data of 1.5 million exposed in SingHealth breach
—Tesla, GM, Toyota, and others expose 157 GB of data
—COSCO hit with ransomware attack

Future malware to recognize victims’ faces

Malware is poised to continue its evolution and deploy newer, more advanced capabilities. In particular, it is believed that threats will leverage artificial intelligence in order to become increasingly context aware. For example, malware may soon employ facial recognition that uses an individual’s appearance to trigger an attack.

Reddit suffers breach

Early last month, a hacker was discovered to have breached Reddit’s systems and stolen a variety of user data; for example, email addresses, passwords, private messages, and more. While the breached data came from an unsecured database containing information from 2005 to 2007, the incident still highlights the importance of maintaining constant visibility and control over data.

6 million records of Georgian voters exposed

Voters in Georgia recently had their personal information exposed when the office of the Secretary of State granted various parties access to voter registration data in an unsecured fashion. This data included dates of birth, drivers license numbers, and Social Security numbers. If the data were obtained by nefarious individuals, widespread identity theft could ensue very easily.

RASPITE Group attacks US infrastructure

Since 2017, the RASPITE Group has been a cybersecurity threat that has attacked nations around the world. Countries in the Middle East, Asia, and Europe have all suffered. Recently, the cybercriminal group was tied to Iran and found to be targeting electric utility companies in the US. Naturally, these organizations must have adequate defenses lying in wait

Decade-old breach at Yale uncovered

About ten years ago, Yale University suffered a breach. Unfortunately, at the time, the intrusion was not detected. Alumni and various faculty and staff had information like Social Security numbers exposed. This event highlights the need for proactive cybersecurity measures as well as constant threat monitoring.

Bug exposes LifeLock customer data

In an ironic twist of fate, LifeLock, an organization built upon defending customers from identity theft, was found to have exposed its users’ email addresses through a bug. The company’s users are now more vulnerable to targeted phishing attacks that imitate communications from LifeLock.

Patient data of 1.5 million exposed in SingHealth breach

Singaporean healthcare organization, SingHealth, was recently breached – much to the ire of those in the country pushing for Singapore to become a cloud-first nation. The cybersecurity incident exposed sensitive information belonging to 1.5 million, including 160,000 whose prescription details were stolen.

Tesla, GM, Toyota, and others expose 157 GB of data

Leading automotive companies (Ford, Volkswagen, and many others) were recently found to have extensive amounts of proprietary information publicly available online. The data was reportedly exposed by poor configurations around rsync protocol, demonstrating, once again, the importance of maintaining a robust and detail-oriented security posture.

COSCO hit with ransomware attack 

As one of the biggest shipping enterprises in the world, COSCO sends countless goods around the globe every day. Unfortunately, the company was recently hit with a ransomware attack that harmed some of its US operations. While the company has since responded to the attacks, ransomware continues to represent an imposing threat for businesses everywhere.

To learn about cloud access security brokers (CASBs) and how they can defend against malware, breaches, and more, download the Definitive Guide to CASBs.

In Europe, Cloud Is the New Default

By Salim Hafid, Senior Product Marketing Manager, Bitglass

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

EMEA leading the cloud charge

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

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

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

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

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

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

Office 365 Security: It Takes Two to Tango

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

By Beth Stackpole, Feature Writer, Symantec

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

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

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

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

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

A holistic security approach

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

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

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

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

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

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

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

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

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

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

Guideline on Effectively Managing Security Service in the Cloud

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

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

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

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

Cloud service security: A how-to

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

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

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

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

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

How Can the Financial Industry Innovate Faster?

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

financial services stock chart

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

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

Cloud security: Who does what?

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

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

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

Allocation of shared responsibility

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

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

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

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

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

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

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

Adopt faster

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

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

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

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

CCSK in the Wild: Survey of 2018 Certificate Holders

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

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

Topics we’ll discuss in this blog:

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

Survey Findings

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

Graph showing How has your career progressed since earning your CCSK

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

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

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

Graph showing salary increase since earning CCSK

Types of Jobs

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

job titles available to CCSK holders

Complementary Certifications

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

graph showing which certifications respondents hold

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

Graph asking which certifications people will pursue

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

Job Board Searches

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

February 2018 Job Search

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

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

October 2018 Job Search

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

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

Overview of Testimonials

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

Survey Testimonials Revealed

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

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

How has the CCSK helped progress your career?

Answers to How as CCSK helped progress your career

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

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

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

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

Internet Cloud server cabinet

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

 

Traditional vulnerability and risk management

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

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

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

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

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

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

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

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

Cloud service customer challenges

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

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

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

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

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

The CVE gap

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

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

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

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

By Sabri KhemissaIT-OT-Cloud Cybersecurity Strategist,Thales

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

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

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

Mitigating Attacks with IoT Firmware Update Guidelines

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

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

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

By Patrick Flanders, Director of Marketing, Lacework

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

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

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

Play it safe with PCI

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

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

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

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

Out of compliance, out of business

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

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

Software-Defined Perimeter Architecture Guide Preview: Part 3

Part 3 in a four-part series

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

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

Information/Infrastructure Hiding

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

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

Mutual Two-way Encrypted Connections

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

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

SDP and the Need-to-Know Access Model

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

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

Dynamic Firewall

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

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

Application Layer Access

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

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

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

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

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

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