eLearning Inside | K-12 Hybrid Learning and Why District IT Teams Must Take a Cloud-First Approach

by ManagedMethods CEO Charlie Sander, for eLearning Inside

When K-12 schools closed their buildings at the start of the COVID-19 pandemic, IT departments’ cybersecurity plans were flipped inside out.

Districts went from monitoring student, teacher, and staff account activity on school networks to flying blind as that activity dispersed across private networks and cloud applications. IT teams are tasked with the challenge of protecting against threats while school data is accessed from anywhere at any time.

Cybersecurity isn’t the only challenge due to school buildings being closed—students may have less supervision to keep them safe from cyber safety incidents. These incidents include cyberbullying, self-harm, threats of violence, racial and LGBTQ discrimination, domestic abuse, and more that occur within popular cloud applications used by schools today.

This fall, when the 2020-21 academic year begins, districts must be ready to monitor their cloud environments more closely, as most student and staff activity will take place in these applications. And when that activity picks back up, district IT admins will face different and more advanced cybersecurity threats than what they experienced previously.


ManagedMethods Launches Google Meet & Chat Monitoring and Reporting to Protect K-12 School Districts From Remote Learning Cybersecurity & Student Safety Risks

ManagedMethods Launches Google Meet & Chat Monitoring Reporting K-12 Cybersecurity and Student Safety PlatformBOULDER, Colo.—May 5, 2020—ManagedMethods, a leading Google G Suite and Microsoft 365 cybersecurity and student safety platform for K-12 school districts, today announced the addition of Google Meet and Chat monitoring and reporting to its platform. District IT teams face new security, safety, and compliance challenges due to increased remote learning and video conferencing in the classroom. ManagedMethods now gives districts full visibility and control into the activity taking place within Google Meet and Chat to address the unique challenges and needs that come with dispersed students and staff.

“The current circumstances due to COVID-19 have rapidly transformed K-12 education, and brought with it new cybersecurity and student safety challenges. Schools are relying on Google Meet for video conferencing and Google Chat for communications,” said Charlie Sander, CEO of ManagedMethods. “Our new Google Meet and Chat monitoring functionality will give IT teams more insight into school meetings to better protect sensitive data, secure remote learning, keep meetings private and students safe.”

New remote learning environments have revealed the limited visibility and control districts previously had over cloud-based file sharing, email, and video conferencing to protect against student safety threats. Districts rely on ManagedMethods to protect their G Suite environments not only from cybersecurity risks, including phishing and malware, data loss, and account takeovers, but also to monitor for student safety signals. These safety concerns include cyberbullying, self-harm, threats of violence, discrimination, and domestic abuse that are found in text and image content.

Now, K-12 IT teams have one, easy-to-use platform where they can quickly identify these issues in their G Suite for Education environment, including Google Meet and Chat. ManagedMethods empowers IT administrators at schools to analyze:

  • Meet Activity: Who attended a meeting, when each attendee joined and how long they were in a meeting, where they joined from, the device used, if screen sharing was enabled by an attendee, and for how long.
  • Participants by Organizational Unit: Which meetings included a teacher or staff member, and which ones did not.
  • Meeting Participants from Outside Domains: All meetings that included an attendee from outside the school domain.
  • Analysis: Easily export Google Meet and Chat data to help build customized reports for analysis and support from district administrators.
  • Compliance: Identify student safety, data security, and privacy compliance issues happening in Chat that may violate FERPA, COPPA, and CIPA standards.

Districts are still responsible for complying with student data privacy regulations, including FERPA, COPPA, and CIPA when conducting remote learning. To do so, IT teams are challenged to secure video meetings from unauthorized access by a non-organizational account – including a parent or guardian account – while all school activity takes place outside the network perimeter.

With ManagedMethods, risks across G Suite for Education, now including Google Meet and Chat, are inside one dashboard. IT teams can easily monitor and audit student safety signals, student data privacy risks, and cybersecurity threats in one, easy-to-use platform. From any location, on any device.

“We consistently heard from our customers who have made the transition to remote learning that Google Meet and Chat use has rapidly increased, and they needed a tool to give them visibility and control into the activity taking place there,” said David Waugh, Chief Revenue Officer of ManagedMethods. “We’re proud to now offer current and future customers the same cybersecurity and student safety monitoring in Meet and Chat that they have for the entire G Suite. Protecting our customers, and their students and staff, is our top priority and these new features will help us achieve that mission.”

ManagedMethods will be hosting a webinar on May 14 at 11:30 a.m. MDT to demonstrate its Google Meet and Chat monitoring and reporting capabilities for school districts. To learn more, please visit the ManagedMethods Google Meet & Chat Demo Webinar registration page.Monitoring Google Meet Chat Webinar - CTA XXL

2019 K-12 Cybersecurity: The Year In Review

How did K-12 cybersecurity fare in 2019?

Are you concerned about cybersecurity? Most K-12 leaders are. You’re gathering an incredible amount of sensitive data about students, and you need to protect your district’s business systems. But, are you doing enough?

It was widely reported that K-12 wasn’t doing enough in 2018. For example, according to a 2018 analysis from SecurityScorecard, an IT security company in New York City, the education industry ranked last in cybersecurity as compared to 17 major industries.

Today, the question is whether 2019 K-12 cybersecurity has improved.



2018 K-12 Cybersecurity Year in Review

A review of the information gathered by the K-12 Cybersecurity Resource Center for 2018 will provide a frame of reference for understanding how things changed in 2019 K-12 cybersecurity.

Schools are increasingly dependent on technology

In 2018, statistics proved that K-12 schools continued an increased reliance on technology for teaching, learning, and school operations. Here are just some examples.

  • In 2013, 4 million students had access to broadband, and that number rose to 44.7 million in 2018.
  • More than 50% of teachers and students use mobile devices.
  • Schools can access real-time information from information systems containing student information.
  • Human resource departments manage payroll and benefits programs online.

The Top 10 Incidents in 2018

2018 saw an alarming number of cybersecurity attacks. The K-12 Cybersecurity Resource Center ranked the Top 10 K-12 Cybersecurity Incidents:

  1. February 2018 in Pennsylvania: An unintentional action put the Pennsylvania Department of Education’s Teacher Information Management System (TIMS) at risk, affecting 330,000 staff.
  2. March 2018 in Texas: A lateral phishing email campaign led to the unauthorized distribution of a district’s W-2 tax forms for all employees.
  3. March 2018 in Florida: A Florida Virtual School inadvertently published confidential student and teacher data on the internet. Hackers put the data up for sale on the dark web.
  4. April 2018 in Massachusetts: A district experienced a ransomware attack. The district was unable to recover and paid $10,000 to the hackers to regain control of critical systems.
  5. May 2018 in California: A student used a phishing email attack to gain access to his school’s grading system, an attack the student described as beginner level.
  6. September 2018, Nationwide: In an unprecedented action, the FBI issued a statement warning school leaders and parents of the privacy and safety issues related to the explosion of EdTech applications and the extensive collection of sensitive student data.
  7. October 2018 in New York: A U.S. Senator asked for Federal aid to combat ongoing distributed denial-of-service (DDoS) attacks that disrupted dozens of New York school districts.
  8. November 2018 in Chicago: An employee left her job at Chicago Public Schools (CPS) and took the personal information for approximately 70,000 people from a database.
  9. November 2018 in Texas: A hacker gained access to a district’s business system and redirected $2 million intended to pay a school construction vendor to a fraudulent account.
  10. December 2018 in California: A hacker used email phishing to collect login credentials for the district’s systems. The resulting data breach included information on over 500,000 individuals.

The 2018 incidents cover a range of attacks including data breaches (46.34%), phishing emails (15.45%), ransomware (9.76%), and denial of service (9.76%). These incidents closed down schools, cost school districts millions of dollars, and put sensitive student and employee data at risk. They affected district operations and the personal lives of students, parents, and employees.



Lessons learned

In 2018, Doug Levin at the K-12 Cybersecurity Resource Center had advice for the K-12 industry to consider for 2019. He urged K-12 stakeholders to set a goal to reduce and manage the cybersecurity risks technology-dependent schools face and to take significant steps to reach that goal.

He also recognized that reaching that goal will require money and new policies and regulations. However, Levin also urged school leaders to share information and to develop and communicate best practices for combatting today’s cybersecurity attacks.

2019 K-12 cybersecurity trends: how did we do?

According to the K-12 Cybersecurity Resource Center, school districts reported a 62% increase in cybersecurity incidents as of December 1, 2019 over 2018. This increase is likely due to a number of factors.

  • There was a 256% increase in data breach incidents.
  • K-12 districts became the second most targeted institutions among attacks on schools, municipalities, law enforcement agencies, and healthcare organizations.
  • Schools are getting better at detecting data breaches, and more open about reporting them.
  • Schools are increasing their use of digital data systems, which makes them more likely to experience accidental exposure.

K-12 cybersecurity is becoming increasingly complex

Another problem is that providing IT for the K-12 sector is becoming more complex, which is straining school districts’ cybersecurity infrastructure and expertise.

K-12 IT teams are responsible for securing 11 different types of devices. Those devices use 258 different operating system versions, and over 6,400 different Chrome extensions. The increase in device usage, known as Bring Your Own Device (BYOD), is increasing the number of endpoints that IT staff must monitor astronomically. While managing access to school systems on school PCs is a challenge, it’s much more complicated when a large number of mobile and other devices are in use.

Schools are using more cloud computing. As a result, sensitive information such as student social security numbers and employee W-2 forms are more at risk now than ever before.

Schools are also using a growing number of classroom management and other EdTech applications, which increase the type of EdTech risks schools must address. In addition, OAuth risks rise with the increase in EdTech usage.

Where do we go from here?

As you probably know, an understanding that there is a K-12 cybersecurity crisis exploded in 2019. School districts and state governments are working hard to make their systems more resistant, and to manage cybersecurity attacks more effectively when they happen.

But, more needs to be done. The challenges faced by K-12 IT staff are unique and evolving. K-12 stakeholders must get serious about prevention by focusing on technology such as cloud security, and by sharing strategies and tactics that work within the K-12 community.


4 Steps to Managing EdTech Security Risks

EdTech security risks create ransomware, account takeover, and data security risks for school districts

New EdTech supports innovation in teaching and enriches learning. However, that same technology can leave you vulnerable to cyberattacks. It poses risks to student privacy and safety, and increases the risks you must face in terms of data breaches and ransomware attacks. Fortunately, there are steps you can take to manage EdTech security risks.

“Shadow” EdTech

Investment in the EdTech sector is growing rapidly. As a result, the number of EdTech SaaS applications that are available to teachers, students, and staff is also growing. Most EdTech applications in use today represent shadow EdTech. Shadow EdTech refers to applications that users are connecting to district Google and/or Microsoft environments through OAuth that you don’t vet or manage from the IT department. Many times you may not even know someone is using them. These applications contribute to the complexity of your district’s IT use and make securing district information systems even more challenging.

Schools Are Targeted by Cybercriminals

Local governments are the most targeted organizations for cybercrime. Education ranks in second place. In July and August 2019, schools reported 160 security problems. That number is higher than the number of all incidents schools reported in 2018.

Years ago, you managed your operating systems, several apps, and a few hundred devices. Now, you’re in a world where your systems include many versions of operating systems, hundreds of apps, and possibly thousands of devices.

Is Reducing Complexity the Answer?

You know that school budgets are restricting your ability to grow your IT department. You certainly don’t have the staff to assign to halting the use of shadow EdTech, and you may not even want to. Therefore, it isn’t possible to put in an immediate fix by reducing the complexity of your environment. You must manage the EdTech security risks that the complexity creates.

How Cyberattacks Have Affected School Districts

Cyberattacks have affected school districts in a variety of ways. Reports show that from January through September 2018, over 500 schools experienced ransomware attacks. Schools in Connecticut were the hardest hit. The state of Louisiana took a unique approach when cybercriminals attacked their schools.

The governor of Louisiana, John Bel Edwards, declared a state of emergency after attacks on three school districts shortly before the new school year started. This approach had the advantage of activating several state and private incident response teams. Those teams helped the school districts recover from the attacks before the districts had to cancel any school days.

It’s difficult to obtain accurate information on the impact of cyberattacks because many school districts don’t report them publicly. Regardless of the numbers you choose to believe, there is a sharp increase in the number of ransomware attacks in 2019.

The problem is so pervasive that the FBI issued a public service announcement encouraging all School District IT teams to raise their awareness of cyber threats. The FBI is especially concerned because schools regularly collect confidential data including personally identifiable, biometric, behavioral, classroom, disciplinary, and medical information. In the wrong hands, this type of data can be devastating to the affected individuals.

Problems Caused by Risky EdTech

Every industry must protect against cloud security risks, and education is no different. Cybercriminals can gain access to your systems in a number of ways. Phishing is a popular tactic. The hackers send emails with infected attachments, and when an unsuspecting user opens the attachment, the infection spreads and allows the hackers access.

When school users login to EdTech apps using their school credentials, they’re creating a potential vulnerability in your systems through a number of OAuth risks. Users love OAuth because they can use one login to access a number of systems. Let’s say a teacher uses their school Google account credentials to login to a classroom management app that uses the OAuth platform. That connection, if not properly secured and maintained, can provide hackers with an access point into your schools’ systems.

Besides ransomware shutting entire districts down, there are other problems caused by EdTech security risks. These issues include:

  • Account Takeovers: Hackers can takeover accounts of teachers and students. The hackers may be able to make purchases using a credit card. They can use their account access to send phishing emails to other contacts and gain access to more accounts and information. Or, they may be able to take over a Facebook profile and send bullying messages to other students based on their personal information. They could also take over an email account for an administrator and wreak all kinds of havoc.
  • Data Loss: Hackers can destroy school records once they have access. They’ve also been known to redirect contractor payments to dummy accounts that the hackers control, and use employee information to steal tax returns. On a personal level, students, staff, and parents can face identity theft, a problem that can take years to resolve.
  • Classroom and Learning Disruption: Whether students are unable to access online lessons, or teachers are unable to prepare and present online lessons, the disruption to the classroom and learning opportunities is a significant problem. Flagstaff school district recently had to cancel school due to a ransomware attack that impacted building security, phones, and other systems.

Managing Your District’s EdTech Security Risks

A survey by the Consortium for School Networking (CoSN) found that system admins rank cybersecurity as both their number one priority and their top challenge. Finding ways to manage EdTech security risks must be a top priority in cybersecurity strategies across the education sector. Here are four steps you can take to address that priority.

1. 24/7 Monitoring

Monitor permission settings and potentially malicious apps that represent OAuth risks. Monitor the activity on your systems to identify abnormal behavior that could result from an account takeover. This activity could be unusual login locations and lateral phishing emails that could indicate an account takeover.

2. Schedule Automatic Action

Identify the EdTech and SaaS applications that are connected to your district G Suite or Office365 systems. Then, automatically classify their risk potential. Once identified, you can take action automatically or manually to sanction, prohibit, remove, or notify the offender. In some cases, more than one of those actions is appropriate.

If your monitoring uncovers a known malicious app, or you determine an app to be malicious, define a procedure for checking with the user. Find out if the user added the app on purpose, or if it could be a result of an account takeover. In this situation, it’s a good idea to suggest that the user reset their account password.

3. Update Your Cloud Safety Measures

Review your G Suite for Education security features to ensure that you’re using them to the fullest. And, conduct a cloud security audit to identify anything you may be missing.

4. Create an EdTech Policy Manual
It’s critical that everyone in your district understands the importance of protecting the security of your data. They should also be aware of the fact that cybercriminals are targeting K-12 institutions. Make sure the manual defines:

  • The EdTech that is approved for use
  • The minimum security and privacy requirements for new EdTech
  • The process for vetting new EdTech apps

Managing your EdTech security risks is one of the best weapons you have against cybercriminals. If your school district doesn’t have an automated system to identify and manage the EdTech apps that are connected to district G Suite and Office 365 environments, your defense isn’t as strong as it could be. Fortunately, identifying EdTech security risks in your environment doesn’t have to be difficult—or particularly expensive. Take the first step in identifying potential EdTech security risks with a free security risk assessment by ManagedMethods!


OAuth Risks and Solutions for K-12

Protect your schools data and information systems from these common OAuth risks

Humans love anything that helps us save steps and time. The development of the OAuth framework does just that for those of us using cloud applications and web services. It allows users to login to one system and then access others without the need to login to each one separately. This single sign-on (SSO) solution works very well and has become the industry standard. However, you do need to understand and address OAuth risks to ensure that your district’s information systems and data remain secure.

What is OAuth?

OAuth is an open-standard authorization framework. In 2010, a group of internet gurus released OAuth as the answer to the common problem of users wasting time by logging in to multiple computer systems. Twitter, Google and others were strong supporters of the project. The developers made significant revisions over the next two years and they released version 2.0 of OAuth in 2012.

OAuth has evolved into a popular standard. It allows unrelated servers to authenticate a user’s access to its data without needing access to the single sign-on credentials, it uses access tokens to verify a user. Internet giants such as Facebook, Amazon, Microsoft, PayPal, and a host of others have adopted it as a de facto standard.

OAuth Examples

You have likely seen OAuth in action. When you go to sign on to a new application, you see the option to use your login credentials from another system. For example, you can choose to use your Google or Facebook login credentials.

It’s also commonly used to send files stored in a cloud application as attachments to an email. If the email client and the cloud storage application support OAuth, you can find the right files and attach them to the email without logging in to the cloud storage application. This type of operation can work between Gmail and Microsoft OneDrive, for example.



Malicious OAuth SaaS Risks

Unfortunately, hackers have found ways to abuse OAuth. It’s simple for an attacker to create an application to get access tokens from unsuspecting users. As a result, while the attacker doesn’t have access to the user’s password, they can use the access token to access email and files. All while bypassing password and two-factor authentication enforcement.

A common example is one in which a hacker creates a “look alike” application that looks much like a trusted app and requires email read, write, and send permissions. Once they are able to trick a user into allowing those permissions, the attacker has unfettered access to their email account. From here, lateral phishing attacks often ensue. Sending phishing links from an internal email account provides the hacker with two advantages. The email is unlikely to be quarantined by phishing filters or MTAs because it is sent from a trusted (internal) domain. Second, recipients are more likely to open the email and click on the link, because there is no reason for them to believe that person would send them malicious content.

Identifying an OAuth attack is notoriously difficult for a few reasons. First, the unsuspecting user may not recall that they’ve allowed access to a 3rd party application, because all of the interaction with the malicious application happens on trusted apps such as Microsoft 365 or Google. Second, traditional cybersecurity infrastructure, such as firewalls and MTAs, are technologically unable to detect the attack. This is because they focus only on securing the perimeter of the network, not the behavior within a cloud application. Finally, few system admins in school districts have access to the visibility and control required to detect and quickly fix OAuth risks in school cloud apps.

It’s likely that OAuth abuse happens more often than we know. The first reported incidents of OAuth abuse occurred during the 2016 election. A hostile espionage group initiated OAuth phishing attacks against political parties in the U.S., Germany, Turkey, and in many other organizations.

EdTech Security Risks

OAuth risks MM Apps TabSchool data systems are increasingly under attack. District IT teams must be vigilant to guard against all types of cybersecurity risks. As you’ve likely experienced yourself, the explosion of EdTech tools and apps have made managing these risks even more difficult.

This is because SaaS infrastructure security is just as critical as any security measures you have in place, but you have much less control over it. EdTech developers that do not take their own infrastructure security seriously, or do not understand the unique needs of data collection and storage in the K-12 environment, place your students’ and district data at risk.

Attackers can use lax EdTech security to gain access to district information. In some cases, they can even gain access to your district’s cloud environment itself using OAuth connections.

In September 2018, the FBI posted a public service announcement related to the risks posed by education technologies. The announcement noted the increase in the use of EdTech in the K-12 environment, and the amount of student data that those systems collect.

Part of the FBI’s concern could be linked to the faulty data configuration settings found in Schoolzilla’s system that was reported in EdSurge. Schoolzilla backed up sensitive data to a public location on Amazon S3. One expert estimated that over one million student records might have been involved.

Schoolzilla responded immediately by securing the data and contacting customers to explain the problem and the solutions Schoolzilla implemented to prevent a recurrence.

EdSurge also reported on the attack on Edmodo that resulted in the theft of over 70 million usernames, email addresses and hashed passwords. They also reported that the data was probably for sale on the dark web.

When you consider these types of breaches, along with phishing attacks, it’s possible that one security breach can lead to a widespread disaster.

How to Mitigate OAuth Risks

OAuth, or something similar to it, is undoubtedly here to stay. Users are demanding easy access and OAuth provides it. However, the K-12 community can take action to protect itself against OAuth risks.

  1. Develop written policies for new EdTech providers. Don’t partner with vendors until they have provided detailed security protocols and have agreed to provide proof of complying with the policies in writing
  2. Create a documented SaaS white and black list for all faculty and staff to reference
  3. Implement a system to monitor SaaS applications and notify your IT team of potential OAuth risks
  4. Implement a system to disconnect risky applications automatically
  5. Monitor accounts for abnormal and/or phishing behavior

A cloud security platform tailored to K-12 IT security needs is the most effective way to accomplish the monitoring and control requirements noted above.

K-12 school districts have a unique duty to safeguard confidential information in order to protect student safety and privacy. If you’re not sure how secure your cloud systems are now, run a cloud security audit. Then, complete the same type of audit on a regular basis to identify potential problem areas and safety issues.


4 Step Cloud Security Audit for School Districts

Keep data secure and students safe with a cloud security audit

K-12 school districts are at the forefront of cloud adoption, being among the first industry sectors to realize the massive benefits of cloud computing. One of several reasons school districts have been eager to make the move is that they need to be able to do more with less.

But while K-12 has adopted cloud computing eagerly, districts are falling woefully behind in cybersecurity—and cloud computing security specifically. Much of the gap has to do with budget and other resource constraints. But there are also understanding and mindset factors that are leaving student data vulnerable to exploitation in school cloud apps.

For example, many IT leaders believe that their content filter does what a cloud security platform will. This couldn’t be further from the truth. The two use completely different technologies, and are used for completely different use cases.

Even more people think that their firewall is enough to protect data in the cloud. In this mistake, K-12 is not alone. There are IT and information security teams in every industry type and organization size that make this mistake. Firewalls are built to protect your district’s network. But data stored in cloud applications like G Suite and Office 365 live outside your district network. Firewalls are no more capable of protecting your data in the cloud than your home security system is capable of stopping your car from being stolen.

Running a cloud security audit will help your IT team see potential data loss prevention, account takeover, ransomware, and other security vulnerabilities in your cloud environment. Using this four step process to auditing district cloud applications will put your team in the best position possible to secure information from identity theft—and help manage student safety risk factors.

Why Audit District Cloud Apps

If your district is using cloud applications for classroom and/or administration, you need to schedule regular cloud security audits. Most school districts that have moved to the cloud are using Google G Suite, Microsoft Office 365, or both to store employee and student data, collaborate on projects, communicate, and more. These cloud applications are built on very secure cloud infrastructures. But, it is your responsibility to secure your district’s accounts from cyber attacks, data loss, and potential student safety issues.

Data security is an often overlooked, but increasingly important topic for K-12 school districts. According to the K-12 Cybersecurity Resource Center, 713 cyber incidents have been reported by K-12 public school districts since 2016. This year alone saw a veritable explosion of ransomware and phishing attacks targeting schools and other public institutions.

Though there is a lack of regulation governing district data security, the time is now to start getting serious about school district cybersecurity.

You can also include a student safety element to scheduling cloud security audits. As more students go online at school, district IT teams are finding themselves at the digital convergence between cybersecurity and cyber safety. At the same time, district IT teams are understaffed, underfunded, and overwhelmed as it is. The insurgence of student cyber safety responsibilities is new—and often unwanted—territory for K-12 IT.

Scheduling regular cloud security audits capable of detecting both data security and student safety issues with automatic reporting is critical for maintaining school infrastructures—and can be a huge win for IT teams.


Step 1: Discover Connected SaaS

OAuth is a fantastic technology that helps people use different SaaS applications without needing to create a separate account for each one. A person can simply login to the application using their Google or Microsoft account.

The downside is that it connects the 3rd party SaaS app to the cloud environment that is used to login through OAuth. System admins are finding it increasingly difficult to manage the explosion of connected SaaS applications to the district cloud environment.

Data security is the biggest concern here. Your district’s data is only as secure as the least secure SaaS application connected to it. If a SaaS vendor is not careful with the security of their own product, it makes your data vulnerable. Criminals are able to use an applications security vulnerabilities to access customer information through OAuth—exposing you to a data breach.

There are also many instances of hackers creating purposefully malicious applications. The goal is to trick someone into connecting to the app through OAuth so they can gain access to your Gmail/Outlook 365, shared drives, contacts, etc.

Auditing the 3rd party SaaS applications connected to your district account can also help control technology costs. You can pull a report of how many applications the district has in its environment to help others determine how much these apps are costing, if they’re being used, etc.

Step 2: Data Loss Prevention

The effectiveness of your data loss prevention rules and policies should be audited regularly. These tend to change as time goes on, and you need to make sure that edits in one place haven’t impacted security in another place.

Data loss can be either accidental or malicious. Most often, it is because an employee unknowingly sets a document to be able to be shared with people who shouldn’t have access to it. Or they accidentally include people on an email who are not the intended recipients. These types of data incidents happen all the time, but they are not harmless. Any time sensitive, personally identifiable information is exposed it can cause damage to the people whose information is shared.

Malicious data loss is what gets all the attention, and is certainly a risk factor that you need to mitigate. Running a regular DLP audit will help you identify if there are any DLP rules and/or policies that need to be adjusted, if new data was created that needs to be secured, or if any information is being used improperly.

Step 3: Account Takeover Detection

Account takeovers are becoming a more common source of phishing, ransomware, data loss, and other cyber threats impacting organizations in the cloud. An account takeover is notoriously difficult to detect and can go on for weeks or months without detection. A cloud audit will help you see abnormalities in account behavior that may indicate an account takeover has occurred, or is currently happening.

Your cloud audit should pull data on:

  • Account login location (by country and/or IP address)
  • Number of login attempts, failures, and successes
  • If phishing, malware, and other suspicious emails are originating from an internal account
  • Abnormal file upload, download, and/or sharing activity

Using this information, you can determine if any accounts are at risk, and then take steps to mitigate and/or remediate the issue.


Step 4: Student Safety & Behavior

School districts are unique from other organizations that do business in the cloud in a number of ways. One of those ways is the responsibility you have for students’ safety—both off and online. If you’re like most school districts, you already have a content filter in place to comply with CIPA and qualify for E-Rate Program funding.

But what about the students that are bypassing the school network? Or using their device outside of the school network? Or students that login to school accounts on personal devices that don’t have the content filter installed? Content filters aren’t equipped to block these kinds of access activity.

We also know that students are using Google Docs as private chat rooms. They are uploading photos and videos to school shared drives. And they are using school email accounts to communicate with each other about personal matters.

Running a cloud security audit with student safety in mind can be made easy with the right kind of setup. You can use student safety specific policies, such as contextual keyword strings, image recognition AI, and sharing and editing behaviors to identify if there is an issue in your Google and/or Office 365 apps. If the audit does find an issue, you can find important information such as who was involved, who it was shared with, why information was shared, etc. All this information is helpful to school counselors and/or campus resource teams who can determine appropriate next steps.

Running regular cloud security audits is an important element of your data security and student safety process. An audit will help you identify potential weaknesses in your cybersecurity infrastructure, as well as detect potential safety hazards. If you’re using a cloud application security platform, you can simply set up automatic audits that will email you reports on a daily, weekly, or monthly basis.


5 Cloud Application Security Best Practices

Best practices for securing data stored in your team’s cloud applications

Just about every organization uses cloud applications in daily operations. Data backup, communications, file storage, and much more is now being managed in the cloud. The biggest (and most troubling) misperception about cloud computing security is that perimeter-based technology works for securing cloud applications. Improve your cloud security operations with these five cloud application security best practices.

Learn More: What is cloud application security? >>

1. Don’t Ignore Due Diligence in Cloud App Selection & Sanctioning

SaaS infrastructure security is something that most of us take for granted. We’re so used to doing business in the cloud, that we connect to tools and applications without thinking twice about potential security consequences. This cavalier approach to technology is causing information security teams a ton of grief. It’s also given rise to the term “Shadow IT”, which has expanded significantly with the use of unsanctioned, or “shadow”, cloud IT.

Every time a new application and/or platform is connected to your company’s cloud environment, a new risk is exposed. The 2018 “Data Risk in the Third-Party Ecosystem” study by Ponemon Institute reported that 59% of companies surveyed experienced a data breach caused by a vendor or third party. While SaaS vendors only make up a portion of that number, it’s a compelling and troubling trend.

As company vendor and third party relationships expand and become more complex, it is critical for information security teams to manage what vendors are being granted access to their IT ecosystem. When it comes to SaaS applications hosted and accessed in the cloud, this task is impossible without the right set of cloud security tools.

But having the right cloud monitoring tools in place is just part of the battle. Information security needs to be involved in helping teams do their due diligence in selecting vendors. Here are six steps to safe SaaS app selection:

1. Know the source: Is the app offered by a reputable developer? Is that developer active in completing updates and patches?
2. Limit excessive permissions: What types of permissions is the app requesting, and does it really need those permissions for its intended purpose?
3. Be mindful of the app’s name: Camouflage is just about the oldest trick in the book. Criminals often create look-alike and sound-alike apps to trick people into downloading them.
4. In-app purchases: Does the app require credit card information for in-app purchases? Does it need to for its intended purpose?
5. Authentication & Encryption: How does the app handle authentication? What encryption methods are used for storing and accessing data? (This is likely something your team will have to help your colleagues out with)
6. Read Reviews! Always read through the app’s reviews to understand what other people have experienced. Be wary of overly complimentary reviews, which could be faked.

[FREE] Cloud Application Security Checklist. Get It Here >>

2. Manage Access to Cloud Applications & User Behavior

Setting up and properly configuring Multi-Factor Authentication (MFA) and Single Sign On (SSO) is access management 101. If you don’t have these set up for your organization’s cloud applications, do it now. Seriously.

You’ll also want to make sure that you set up user groups within your main applications (typically Google G Suite and/or Microsoft Office 365) to manage who can access what. For example, not everyone in the organization needs access to business financial data or HR information. Segmenting information and only allowing access by specific users who need access to them significantly improves your data security posture.

But there is more that can be done. Account takeovers are on the rise, and can lead to all kinds of problems. Putting a block on IP address locations for logins, for example, go a long way in significantly reducing your risk of an account takeover. Monitoring for a spike in the number of failed login attempts will also help your team detect when your environment is currently under attack, so steps can be made to fortify account access. Perhaps a password change is in order. Or a simple communication to the organization to be hyper-vigilant for phishing emails can go a long way to thwarting attacks.

Monitoring for abnormal user behavior is another way to detect if an account takeover is occuring. These behaviors could include phishing emails being sent from an internal account, bulk downloading of files, and importing of files containing malware links to your shared drives.

We hate to think about it, but internal threats are also something that teams need to monitor for. Data breaches that involve disgruntled or otherwise compromised employees happen, and they are just as harmful (if not moreso) than one created externally. Customer and/or employee information, trade secrets, and financial data are all assets that an employee may decide to use for their own gain.

By monitoring user behavior, security teams can detect if information is potentially being improperly handled by internal users, as well as external attacks.

3. Cloud Phishing & Malware Threat Protection

Email is still the #1 threat vector. Protecting email, whether they are hosted in the cloud like Gmail or otherwise, should be a top concern for security teams. Cloud malware threat protection works a little differently than traditional perimeter-based security technology, like proxies and gateways. Criminals are increasingly finding ways to circumvent perimeter-based security for organizations that use cloud-based email platforms.

We’re increasingly finding that native email filters provided by Google and Microsoft are also susceptible to a significant vulnerability. These filters are set to automatically “whitelist” links coming from their own domain. Now, there are more incidents where hackers upload a file containing a malicious link to Google Drive or SharePoint, and then send the file link in an email.

Adding a cloud-specific protective layer to your cloud-based email apps is now as critical to a secure infrastructure as traditional email filters.

4. Automate & Remediate Cloud Application Security Risks

Information security teams are notoriously under-staffed and under-funded, particularly in small to mid-sized organizations. Cybersecurity awareness in the executive suite is certainly improving, but we still have a long way to go. Using tools that can help small, overwhelmed teams operate more efficiently is key.

A Cloud Access Security Broker (CASB) helps automate cloud app security risk detection and remediation 24/7. It makes each of these cloud application security best practices actually happen, day in and day out, for security teams.

Using a CASB, you can set up data loss prevention rules and policies that will automatically detect abnormal behavior, improper use of information, malware and phishing threats, shadow cloud IT, and more. The technology will then take the remediation action that you select to quarantine, delete, revoke access, etc. automatically, making your job much easier.

See CASB In Action! Click Here For A Quick Demo On-Demand >>

5. Audit & Optimize

All good cybersecurity teams consistently audit and optimize their security infrastructure and posture. Depending on the size and complexity of your data environment, this may happen on a weekly, monthly, or quarterly basis. Whatever your time scale is, make sure you are auditing your cloud security often enough, and consistently.

This is another area where CASBs can help. Using a CASB, you can set up audit reports that you would like it to run on a periodic basis. This way, you get the reports you need sent directly to you, rather than needing to set up the same report over and over again.

An audit will show you where new vulnerabilities have opened up, if you have unsanctioned apps sneaking back into your environment, etc. Keeping an eye on these risks and trends overtime will help you optimize how you’ve set up your rules and policies, making your CASB work even better for you over time.

There is no perimeter in the world of cloud computing. Using technology meant for defending a perimeter to secure cloud applications is ineffective, and creates unnecessary vulnerabilities. Following these cloud application security best practices, paired with the right kind of technology, will close the vulnerability gap while providing your security team with the visibility and control they need to do their jobs effectively in the cloud.

Cloud Application Security Checklist Blog CTA XXL

CASBs: Is It Time To Remove The “Broker” From Cloud Access Security Broker?

How are you securing your organization’s data in cloud applications?

Cloud Access Security Brokers are now an integral part of any organization’s IT security infrastructure. IT leaders are realizing just how important cloud security is. As more organizations move to the cloud and more employees rely on cloud-based SaaS applications, such as G Suite and Office 365, the need to secure data in the cloud is greater than ever.

IT leaders are much more aware of what cloud access security brokers (CASBs) are than they were just a couple of years ago. But, in the short time since the term was coined, there have been some changes in available technology that beg the question: Is it time to remove the “broker” from cloud access security broker?

What is a Broker?

The dictionary definition of a broker is one who acts as an intermediary, this is how you can think of a “broker” in the cybersecurity world.

A broker routes traffic from inside a network to the Internet (and vice versa), the extent to which it is able to filter and control this traffic depends on the type of broker. In the early days of cloud security, all the available technology was built using some sort of broker. This includes gateways, proxies, and agents—all of which are lumped into the generic term “broker”.

What is a Cloud Access Security Broker?

So, what is a CASB? CASBs are enforcement points between a customer and a cloud service vendor. The term was coined by Gartner in 2014 to help describe the relatively new industry of cloud security vendors. The first CASB Gartner Magic Quadrant was published in 2017.

At the time, most CASB vendors were still using a broker-type appliance to secure access to cloud applications. These types of solutions work like a firewall; they take information that is trying to gain access to a company’s internal network from the Internet, and filter it through policy enforcements. If the information is flagged by the firewall or CASB, access is rejected. In fact, the traditional CASB is so much like a firewall that it usually duplicates the security controls most companies already have in place, which increases cost and complexity.

Most CASB solutions claiming to use a “broker”, are simply using an agent or proxy. Some use browser extensions and call their product “agentless”. While they’re not using an agent specifically, they are still using a broker.

Why Do CASBs Need a Broker?

CASBs - No Agents No Proxies BrokerlessCASBs don’t need a broker per se. It’s a term that was created before API cloud security technology entered the market space, but it is important to know that there are distinct differences between an API vs. proxy CASB.

Proxy-based CASBs (or any CASB that uses a type of “broker”) put a checkpoint between the user and the cloud application to check and verify before granting access to the app. The biggest benefit is that it can take security action in real-time, and some can stop an outgoing email that contains sensitive information, based on the organization’s data loss prevention policies, even after it’s been sent.

The disadvantages are that broker-based CASBs can be cumbersome to set up and deploy,  they significantly reduce network speed and slow down user productivity, and they don’t have the ability to monitor the behavior within a cloud app. They simply filter information going in and out of the cloud app within the organization’s network. Broker CASB security can also be broken merely by cloud application updates.

API-based CASBs don’t actually use a broker at all. While these types of platforms still fall under the Cloud Access Security Broker industry category, they don’t really fit the literal term. They’re more like Cloud Application Security Platforms (CASP) because they build deep, one-to-one integrations with cloud apps using native APIs. This is important because API CASBs are able to function almost like a native feature of the application it secures.

The main benefit of API-based CASB architecture is that it can be up and running (and securing) the data in your cloud applications in mere minutes. They also don’t place any sort of filter between user access and the application, so it doesn’t slow down network speed and it won’t impact end-user experience. API CASBs can monitor and control behavior within cloud applications at a much deeper level, ensuring that your actual information and data are protected, instead of just the perimeter.

The disadvantages of an API-based CASB are that there can be a split-second delay in some security functionalities. They also cannot stop outgoing emails after they are sent like a broker CASB can. Because, again, there is no appliance between the application and user access. Both of these disadvantages; however, are usually covered by a company’s firewall and/or secure gateway that are already installed.

Perhaps it’s merely a case of semantics. But the distinctions in how CASB solutions work is important for anyone looking to secure company data that is stored, accessed, and shared in the cloud. More expensive and more complicated does not mean more secure. Your choice in cloud application security should rely on more than just a magic quadrant, it must take into account your organization’s needs and the IT security infrastructure that you already have in place.

Brokerless CASBs Demo-On-Demand - Blog CTA XXL

Cloud Application Security Audit Checklist

Configure settings and mitigate risks with this cloud application security checklist

Using Google G Suite and Microsoft Office 365 provides school districts with many benefits. From improving productivity and collaboration to outsourcing infrastructure security, schools and districts of sizes are making the move to the cloud.

But there are security issues in cloud computing. The NIST Cybersecurity Framework recommends that you run a risk assessment and cloud security audit regularly. This cloud application security checklist is designed to help you run such an audit for your district’s G Suite and Office 365 to mitigate security issues.

Cloud Application Security Checklist Mid-Blog CTA10 Step Cloud Application Security Audit Checklist

What is cloud application security? It is a series of defined policies, processes, controls, and technology governing all information exchanges that happen in collaborative cloud Software as a Service (SaaS) applications like Microsoft Office 365 and Google G Suite.

As your school district moves more information and activity to the cloud, your perimeter security safeguards become less effective. More IT and security professionals are opting to secure cloud storage by deploying a zero trust security model. This checklist also helps you lay the groundwork for deploying zero trust security for your district’s cloud applications.

1. Set password policies

Passwords are the foundation of any good security plan. Educate both students and staff on what factors make passwords strong or weak, and why password strength is so important.

As a system admin, you can set policies and standards for your district’s cloud app passwords. At a minimum, you should enable your system’s “require a strong password” feature. You can also set minimum and maximum password lengths, password expiration, and more.

If you’re setting the standards for the first time, be sure to run a check of current passwords to see whose passwords are out of compliance with the new standards. You can then force a password change through your admin console.

2. Make multi-factor authentication mandatory

Multi-factor authentication requires users to take a second step, after entering the correct password, to prove they have authorized access. This typically includes entering a code that is sent to their phone via SMS. It can also include phone calls, answering security questions, mobile app prompts, and more.

3. Manage SaaS access and permissions

Open Authorization (OAuth) makes app use convenient for end-users, but it can be a little bit of a nightmare for those in charge of IT security. The proliferation of SaaS use in classrooms and throughout school districts makes it difficult to stay on top of what apps have access to your cloud environment, what permissions are granted to them, and how secure the app is itself.

District system admins have the ability to control what apps are allowed permissions to the company’s Google or Microsoft cloud accounts. This can be as simple as restricting access to risky apps, or as customized and detailed as creating sanctioned and unsanctioned apps lists.




4. Enable anti-phishing protections

Email phishing is still the most common external threat vector. And there is a myriad of tools on the market aimed at removing phishing emails from inboxes. Unfortunately, none of them work with 100% accuracy.

The best option is to start with configuring your native cloud email provider’s anti-phishing capabilities and then layer additional safeguards and monitors on top of it. Educating the rest of your district about common phishing attacks, new ones as they arise, and how to spot them is also extremely important.

5. Turn on unintended external reply warning

One of the ways you can ensure that sensitive, internal information isn’t improperly shared outside of the school district is to enable an external reply warning. This feature also protects your district against forged emails from malicious hackers trying to gain access to internal files and information.

When the external reply warning is enabled, users receive a pop-up notification asking if they’re sure they want to send it to an external domain. It’s important to reinforce to your colleagues why they need to pay attention to this pop-up and think twice before dismissing it.

6. Set external sharing standards

Beyond sending emails, you should configure data loss prevention external sharing standards for shared calendars, drives, folders, and files. The best approach is to start with the most strict standards possible, and then open up as needed.

Files and folders containing the most sensitive information such as student, parent/guardian, and staff personally identifiable and financial information, should rarely (if ever) be configured to allow external sharing and access.

7. Set up message encryption

Encryption prevents anyone other than the intended audience from viewing a message. Microsoft and Google provide native encryption options. In Google’s case, they provide “Confidential Mode”, which works a little differently. There are also a variety of third party encryption tools available.

Sending sensitive or confidential information via email should always have encryption and confidential protections enabled. It forces the recipient to authenticate that they are the intended audience and protects the information from being forwarded to others. The sender can also set up an expiration date to ensure the information isn’t lingering in someone’s inbox into eternity.

8. Set up data loss prevention policies

Fundamentally, data loss prevention is a strategy to ensure that your district’s sensitive and protected information does not inadvertently leave the network—whether it’s accidental or malicious.

System admins have the ability to set up data loss prevention policies in most popular and “enterprise-level” cloud applications. These policies help admins maintain and automate rules around how information can be accessed and shared. Most policies create alerts and actions that the system can take if a data loss prevention policy is broken. For example, if an employee account is trying to share a spreadsheet containing social security numbers with an outside domain, the policy can be set up to automatically warn the user and/or quarantine the file.




9. Enable mobile management

Everyone in your school district likely uses mobile devices to access school cloud accountsmainly email, files, and drives. These mobile devices represent more endpoints that need to be secured by IT. But, endpoint security isn’t enough in cloud computing security. You will also need to configure mobile device policies in your cloud applications.

10. Run a security health/score audit

Once you’ve completed this checklist, it’s a good idea to run a cloud security audit of your environment. An audit will re-check for any configuration errors, sharing risks, files containing sensitive information, and more.

It’s also important to run an audit on a periodic basis. Weekly and/or monthly audits and reports can be automated and provide you with detailed information into the security health of your cloud applications. Microsoft provides Office 365 Secure Score, which is very helpful in providing on-going health checks and recommendations. Particularly as new security features are rolled out and new risks are identified.

If your school district uses SaaS applications such as G Suite and/or Office 365, cloud application security is a critical layer in your cybersecurity infrastructure. Without it, monitoring and controlling behavior happening within applications are impossible. This blind spot creates critical vulnerabilities in your district stakeholders’ sensitive information and financial futures.

Cloud Application Security Checklist Blog CTA XXL

Cloud Application Security Architecture for SaaS Security

The architecture of cloud application security platforms is important to your purchase decision

If you are looking to secure cloud storage for your company or organization, you’re likely to find a baffling number of options on the market. An important aspect of your purchase decision is how the security platform is built. Consideration of the cloud application’s security architecture is critical not just for the app developer, but for you as the customer! The application must be built for optimum service, performance, and functionality.

Some platforms have sleek designs and friendly user experience. Others can be overly complicated and difficult to find the information you need to identify and remediate risks. With security issues in cloud computing becoming a reality for system administrators of companies of all sizes, the most important aspects of cloud appliaction secuirty are that it is easy to use and works well.

Why Cloud Native Architecture is Important for SaaS

Cloud native” architecture broadly refers to applications that are created and deployed in the cloud, using cloud development techniques like Infrastructure as a Service (IaaS) and multicloud. It means that the application exists in the cloud, rather than in on-premise data centers.

There are many benefits to using Software as a Service (SaaS) products that are built using cloud native architecture, instead of traditional software and/or web-based apps. Here are the top three reasons why cloud native architecture is important for SaaS.

1. Redundancy and Resilience

While being redundant is frowned upon in writing and speaking, it is definitely considered a perk in cybersecurity. Cloud-based  security architecture enjoys benefits in redundancy and resilience. Since the application is hosted in the cloud, it isn’t reliant on a single set of servers or one data center. If there is an outage in one region, hosting will simply shift to another region.

Cloud applications are by no means immune to outages. However, when a cloud application is used, instead of on-prem software, there is the benefit of redundancy built into the hosting architecture that allows it to shift from one region to another; this could cause delays in app performance, but it is much better than a complete outage.

When an outage does occur, it’s being taken care of by a team of architects and engineers that are paid for and managed by the infrastructure provider. In other words, large companies such as Google, Microsoft, or Amazon are able to employ a much larger and more skilled team to work on the issue than most companies. When an outage occurs on your on-prem software, your one to two member IT team must drop everything and put all their resources to getting the servers back up and running. Depending on the cause of the outage, this could take minutes or days.

When you’re thinking in terms of data and app security, which application architecture (and support team) would you prefer?

2. Elasticity & Scalability

Hosting an application in the cloud provides unlimited computing resources, this allows the app to dynamically adjust to workload requests in a way that traditional software can’t. This is referred to as cloud elasticity.

Cloud scalability works similarly, but it refers to an application’s ability to continually increase workload demand using its existing infrastructure, without decreasing performance or requiring extensive new development.

Both of these concepts are critical when you’re considering your options in cloud application security architecture. Choosing a cloud-native security app means it will be built to perform critical security functions, even as its workload demands surge and recede. You don’t want a cloud security platform that breaks right as call demands spike (possibly signaling an attack)!

3. Automated Updates

Cloud applications are always up to date, and never need users to restart their computer or device to complete an update. This is an important differentiator to on-premise software that requires downloads and downtime, and typically roll out updates at a much slower pace.

Many people tend to think about updates in terms of new app features and/or user experience. But updates are more often used to fix bugs and patch security vulnerabilities within the app or software. When software updates are ignored, which happens often because IT and/or employees don’t want to have to stop what they’re doing to restart, it could be opening critical risks in your cybersecurity infrastructure.

This isn’t a concern with cloud applications, which will update as soon as the developer rolls them out across all tenants. So, when you choose a cloud security platform that is built in the cloud, you’re enjoying the benefit of always having the most up-to-date application available—without any downloads or downtime on your part.

[LEARN MORE] What Is Cloud Application Security? >>

cloud application security architecture - 900px

Cloud Application Security Architecture Infrastructure

Most cloud native applications are built using an Infrastructure as a Service vendor. The most common IaaS vendors are Amazon Web Services, Microsoft Azure, and Google Cloud Platform.

When you’re working with a cloud SaaS application, you don’t have to worry about maintaining the infrastructure of the application—that’s the responsibility of the vendor. But, it is important to have at least a basic understanding of where the application is hosted and built, so you know what you can expect in terms of service level metrics.

Infrastructure considerations are particularly important when you’re comparing cloud application security platforms. Infrastructure is a critical piece of the platform’s architecture. You’ll want to make sure it’s being built and hosted on a reliable infrastructure. Amazon, Azure, and Google Cloud all have their different strengths and weaknesses, so infrastructure shouldn’t be your only deciding factor. But, it should definitely be part of the conversation, and it should leverage one of the top three tried and true providers to ensure optimal application uptime and performance.

Cloud App Security Common Components & Services

On a very basic level, component-based SaaS architecture means that the developer has developed different “microservices” and “components” that work together, but are essentially independent of each other.

The benefit of this type of containerized architecture, if you will, is that it allows for greater flexibility and scalability than an app that has been essentially built as a monolith. It makes it much easier for developers to remove and/or replace different containers with better optimized components and services, at a much faster rate. It also means that, if there is more workload demand for a certain service, the app can direct more resources to it, rather than slowing down the application as a whole.

When it comes to the architecture of cloud application security platforms, there are many ways that developers can manage component-based development. It may break down something like this:

Common Components

Common Services

  • Malware scanning
  • Risk scanning
  • Anti-phishing
  • Map visualization
  • OAuth apps

APIs To Connect Them All

Application Programming Interface (API) basically allows applications to communicate with each other. These days, application developers most often use RESTful API standards to create connections between their application and another. APIs are popular because they allow two applications to work together almost as though they were one.

Today’s cloud application security architecture is built using one of two very different types of security connections. They will either use APIs to build deep, one-to-one connections between the cloud application and the security platform so they work almost as though they were the same application. Or it’ll use a proxy, agent, extension, or some kind of gateway to stop and scan traffic outside of the cloud application it is attempting to secure.

There are pros and cons to both of these approaches. One of the biggest benefits to API-based cloud application security architecture is that it is able to monitor and secure activity within the cloud application, not just attempts outside of the app (as in the case of a proxy-based platform). It becomes one of your greatest SaaS security layers within your zero trust security strategy.

When it comes to securing the sensitive data stored, accessed, and shared in your company’s cloud applications, you need to make informed decisions. This is why the architecture of the cloud application security platforms you are considering is so important to your purchase decision. Take the time to understand what your needs are, and how the capabilities of cloud security apps align with those needs!

zero trust security - demo on-demand CTA

Portfolio Items