Cloudflare is on a mission to help build a better Internet, and we are committed to doing this with ethics and integrity in everything that we do. This commitment extends beyond our own actions, to third parties acting on our behalf. Cloudflare has the same expectations of ethics and integrity of our suppliers, resellers, and other partners as we do of ourselves.
Our new code of conduct for third parties
We first shared publicly our Code of Business Conduct and Ethics during Cloudflare’s initial public offering in September 2019. All Cloudflare employees take legal training as part of their onboarding process, as well as an annual refresher course, which includes the topics covered in our Code, and they sign an acknowledgement of our Code and related policies as well.
While our Code of Business Conduct and Ethics applies to all directors, officers and employees of Cloudflare, it has not extended to third parties. Today, we are excited to share our Third Party Code of Conduct, specifically formulated with our suppliers, resellers, and other partners in mind. It covers such topics as:
Human Rights
Fair Labor
Environmental Sustainability
Anti-Bribery and Anti-Corruption
Trade Compliance
Anti-Competition
Conflicts of Interest
Data Privacy and Security
Government Contracting
But why have another Code?
We work with a wide range of third parties in all parts of the world, including countries with a high risk of corruption, potential for political unrest, and also countries that are just not governed by the same laws that we may see as standard in the United States. We wanted a Third Party Code of Conduct that serves as a statement of Cloudflare’s core values and commitments, and a call for third parties who share the same.
The following are just a few examples of how we want to ensure our third parties act with ethics and integrity on our behalf, even when we aren’t watching:
We want to ensure that the servers and other equipment in our supply chain are sourced responsibly, from manufacturers who respect human rights — free of forced or child labor, with environmental sustainability at the forefront.
We want to provide our products and services to customers based on the quality of Cloudflare, not because a third party reseller may bribe a customer to enter into an agreement.
We want to ensure there are no conflicts of interest with our third parties, that might give someone an unfair advantage.
As a government contractor, we want to ensure that we do not have telecommunications or video surveillance equipment, systems, or services from prohibited parties in our supply chain to protect national security interests.
Having a Third Party Code of Conduct is also industry standard. As Cloudflare garners an increasing number of Fortune 500 and other enterprise customers, we find ourselves reviewing and committing to their Third Party Codes of Conduct as well.
How it works
Our Third Party Code of Conduct is not meant to replace our terms of service or other contractual agreements. Rather, it is meant to supplement them, highlighting Cloudflare’s ethical commitments and encouraging our suppliers, resellers, and other partners to commit to the same. We will be cascading this new Code to all existing third parties, and include it at onboarding for all new third parties going forward. A violation of the Code, or any contractual agreements between Cloudflare and our third parties, may result in termination of the relationship.
This Third Party Code of Conduct is only one facet of Cloudflare’s third party due diligence program, and it complements the other work that Cloudflare does in this area. Cloudflare rigorously screens and vets our suppliers and partners at onboarding, and we continue to routinely monitor and audit them over time. We are always looking for ways to communicate with, educate, and learn from our third parties as well.
Join our mission
Are you a supplier, reseller or other partner who shares these values of ethics and integrity? Come work with us and join Cloudflare on its mission to help build a better, more ethical Internet.
The Border Gateway Protocol (BGP) is the glue that keeps the entire Internet together. However, despite its vital function, BGP wasn’t originally designed to protect against malicious actors or routing mishaps. It has since been updated to account for this shortcoming with the Resource Public Key Infrastructure (RPKI) framework, but can we declare it to be safe yet?
If the question needs asking, you might suspect we can’t. There is a shortage of reliable data on how much of the Internet is protected from preventable routing problems. Today, we’re releasing a new method to measure exactly that: what percentage of Internet users are protected by their Internet Service Provider from these issues. We find that there is a long way to go before the Internet is protected from routing problems, though it varies dramatically by country.
Why RPKI is necessary to secure Internet routing
The Internet is a network of independently-managed networks, called Autonomous Systems (ASes). To achieve global reachability, ASes interconnect with each other and determine the feasible paths to a given destination IP address by exchanging routing information using BGP. BGP enables routers with only local network visibility to construct end-to-end paths based on the arbitrary preferences of each administrative entity that operates that equipment. Typically, Internet traffic between a user and a destination traverses multiple AS networks using paths constructed by BGP routers.
BGP, however, lacks built-in security mechanisms to protect the integrity of the exchanged routing information and to provide authentication and authorization of the advertised IP address space. Because of this, AS operators must implicitly trust that the routing information exchanged through BGP is accurate. As a result, the Internet is vulnerable to the injection of bogus routing information, which cannot be mitigated by security measures at the client or server level of the network.
An adversary with access to a BGP router can inject fraudulent routes into the routing system, which can be used to execute an array of attacks, including:
Denial-of-Service (DoS) through traffic blackholing or redirection,
Impersonation attacks to eavesdrop on communications,
Machine-in-the-Middle exploits to modify the exchanged data, and subvert reputation-based filtering systems.
Additionally, local misconfigurations and fat-finger errors can be propagated well beyond the source of the error and cause major disruption across the Internet.
Such an incident happened on June 24, 2019. Millions of users were unable to access Cloudflare address space when a regional ISP in Pennsylvania accidentally advertised routes to Cloudflare through their capacity-limited network. This was effectively the Internet equivalent of routing an entire freeway through a neighborhood street.
The most prominent proposals to secure BGP routing, standardized by the IETF focus on validating the origin of the advertised routes using Resource Public Key Infrastructure (RPKI) and verifying the integrity of the paths with BGPsec. Specifically, RPKI (defined in RFC 7115) relies on a Public Key Infrastructure to validate that an AS advertising a route to a destination (an IP address space) is the legitimate owner of those IP addresses.
RPKI has been defined for a long time but lacks adoption. It requires network operators to cryptographically sign their prefixes, and routing networks to perform an RPKI Route Origin Validation (ROV) on their routers. This is a two-step operation that requires coordination and participation from many actors to be effective.
The two phases of RPKI adoption: signing origins and validating origins
RPKI has two phases of deployment: first, an AS that wants to protect its own IP prefixes can cryptographically sign Route Origin Authorization (ROA) records thereby attesting to be the legitimate origin of that signed IP space. Second, an AS can avoid selecting invalid routes by performing Route Origin Validation (ROV, defined in RFC 6483).
With ROV, a BGP route received by a neighbor is validated against the available RPKI records. A route that is valid or missing from RPKI is selected, while a route with RPKI records found to be invalid is typically rejected, thus preventing the use and propagation of hijacked and misconfigured routes.
One issue with RPKI is the fact that implementing ROA is meaningful only if other ASes implement ROV, and vice versa. Therefore, securing BGP routing requires a united effort and a lack of broader adoption disincentivizes ASes from commiting the resources to validate their own routes. Conversely, increasing RPKI adoption can lead to network effects and accelerate RPKI deployment. Projects like MANRS and Cloudflare’s isbgpsafeyet.com are promoting good Internet citizenship among network operators, and make the benefits of RPKI deployment known to the Internet. You can check whether your own ISP is being a good Internet citizen by testing it on isbgpsafeyet.com.
Measuring the extent to which both ROA (signing of addresses by the network that controls them) and ROV (filtering of invalid routes by ISPs) have been implemented is important to evaluating the impact of these initiatives, developing situational awareness, and predicting the impact of future misconfigurations or attacks.
Measuring ROAs is straightforward since ROA data is readily available from RPKI repositories. Querying RPKI repositories for publicly routed IP prefixes (e.g. prefixes visible in the RouteViews and RIPE RIS routing tables) allows us to estimate the percentage of addresses covered by ROA objects. Currently, there are 393,344 IPv4 and 86,306 IPv6 ROAs in the global RPKI system, covering about 40% of the globally routed prefix-AS origin pairs1.
Measuring ROV, however, is significantly more challenging given it is configured inside the BGP routers of each AS, not accessible by anyone other than each router’s administrator.
Measuring ROV deployment
Although we do not have direct access to the configuration of everyone’s BGP routers, it is possible to infer the use of ROV by comparing the reachability of RPKI-valid and RPKI-invalid prefixes from measurement points within an AS2.
Consider the following toy topology as an example, where an RPKI-invalid origin is advertised through AS0 to AS1 and AS2. If AS1 filters and rejects RPKI-invalid routes, a user behind AS1 would not be able to connect to that origin. By contrast, if AS2 does not reject RPKI invalids, a user behind AS2 would be able to connect to that origin.
While occasionally a user may be unable to access an origin due to transient network issues, if multiple users act as vantage points for a measurement system, we would be able to collect a large number of data points to infer which ASes deploy ROV.
If, in the figure above, AS0 filters invalid RPKI routes, then vantage points in both AS1 and AS2 would be unable to connect to the RPKI-invalid origin, making it hard to distinguish if ROV is deployed at the ASes of our vantage points or in an AS along the path. One way to mitigate this limitation is to announce the RPKI-invalid origin from multiple locations from an anycast network taking advantage of its direct interconnections to the measurement vantage points as shown in the figure below. As a result, an AS that does not itself deploy ROV is less likely to observe the benefits of upstream ASes using ROV, and we would be able to accurately infer ROV deployment per AS3.
Note that it’s also important that the IP address of the RPKI-invalid origin should not be covered by a less specific prefix for which there is a valid or unknown RPKI route, otherwise even if an AS filters invalid RPKI routes its users would still be able to find a route to that IP.
The measurement technique described here is the one implemented by Cloudflare’s isbgpsafeyet.com website, allowing end users to assess whether or not their ISPs have deployed BGP ROV.
The isbgpsafeyet.com website itself doesn’t submit any data back to Cloudflare, but recently we started measuring whether end users’ browsers can successfully connect to invalid RPKI origins when ROV is present. We use the same mechanism as is used for global performance data4. In particular, every measurement session (an individual end user at some point in time) attempts a request to both valid.rpki.cloudflare.com, which should always succeed as it’s RPKI-valid, and invalid.rpki.cloudflare.com, which is RPKI-invalid and should fail when the user’s ISP uses ROV.
This allows us to have continuous and up-to-date measurements from hundreds of thousands of browsers on a daily basis, and develop a greater understanding of the state of ROV deployment.
The state of global ROV deployment
The figure below shows the raw number of ROV probe requests per hour during October 2022 to valid.rpki.cloudflare.com and invalid.rpki.cloudflare.com. In total, we observed 69.7 million successful probes from 41,531 ASNs.
Based on APNIC’s estimates on the number of end users per ASN, our weighted5 analysis covers 96.5% of the world’s Internet population. As expected, the number of requests follow a diurnal pattern which reflects established user behavior in daily and weekly Internet activity6.
We can also see that the number of successful requests to valid.rpki.cloudflare.com (gray line) closely follows the number of sessions that issued at least one request (blue line), which works as a smoke test for the correctness of our measurements.
As we don’t store the IP addresses that contribute measurements, we don’t have any way to count individual clients and large spikes in the data may introduce unwanted bias. We account for that by capturing those instants and excluding them.
Overall, we estimate thatout of the four billion Internet users, only 261 million (6.5%) are protected by BGP Route Origin Validation, but the true state of global ROV deployment is more subtle than this.
The following map shows the fraction of dropped RPKI-invalid requests from ASes with over 200 probes over the month of October. It depicts how far along each country is in adopting ROV but doesn’t necessarily represent the fraction of protected users in each country, as we will discover.
Sweden and Bolivia appear to be the countries with the highest level of adoption (over 80%), while only a few other countries have crossed the 50% mark (e.g. Finland, Denmark, Chad, Greece, the United States).
ROV adoption may be driven by a few ASes hosting large user populations, or by many ASes hosting small user populations. To understand such disparities, the map below plots the contrast between overall adoption in a country (as in the previous map) and median adoption over the individual ASes within that country. Countries with stronger reds have relatively few ASes deploying ROV with high impact, while countries with stronger blues have more ASes deploying ROV but with lower impact per AS.
In the Netherlands, Denmark, Switzerland, or the United States, adoption appears mostly driven by their larger ASes, while in Greece or Yemen it’s the smaller ones that are adopting ROV.
The following histogram summarizes the worldwide level of adoption for the 6,765 ASes covered by the previous two maps.
Most ASes either don’t validate at all, or have close to 100% adoption, which is what we’d intuitively expect. However, it’s interesting to observe that there are small numbers of ASes all across the scale. ASes that exhibit partial RPKI-invalid drop rate compared to total requests may either implement ROV partially (on some, but not all, of their BGP routers), or appear as dropping RPKI invalids due to ROV deployment by other ASes in their upstream path.
To estimate the number of users protected by ROV we only considered ASes with an observed adoption above 95%, as an AS with an incomplete deployment still leaves its users vulnerable to route leaks from its BGP peers.
If we take the previous histogram and summarize by the number of users behind each AS, the green bar on the right corresponds to the 261 million users currently protected by ROV according to the above criteria (686 ASes).
Looking back at the country adoption map one would perhaps expect the number of protected users to be larger. But worldwide ROV deployment is still mostly partial, lacking larger ASes, or both. This becomes even more clear when compared with the next map, plotting just the fraction of fully protected users.
To wrap up our analysis, we look at two world economies chosen for their contrasting, almost symmetrical, stages of deployment: the United States and the European Union.
112 million Internet users are protected by 111 ASes from the United States with comprehensive ROV deployments. Conversely, more than twice as many ASes from countries making up the European Union have fully deployed ROV, but end up covering only half as many users. This can be reasonably explained by end user ASes being more likely to operate within a single country rather than span multiple countries.
Conclusion
Probe requests were performed from end user browsers and very few measurements were collected from transit providers (which have few end users, if any). Also, paths between end user ASes and Cloudflare are often very short (a nice outcome of our extensive peering) and don’t traverse upper-tier networks that they would otherwise use to reach the rest of the Internet.
In other words, the methodology used focuses on ROV adoption by end user networks (e.g. ISPs) and isn’t meant to reflect the eventual effect of indirect validation from (perhaps validating) upper-tier transit networks. While indirect validation may limit the “blast radius” of (malicious or accidental) route leaks, it still leaves non-validating ASes vulnerable to leaks coming from their peers.
As with indirect validation, an AS remains vulnerable until its ROV deployment reaches a sufficient level of completion. We chose to only consider AS deployments above 95% as truly comprehensive, and Cloudflare Radar will soon begin using this threshold to track ROV adoption worldwide, as part of our mission to help build a better Internet.
When considering only comprehensive ROV deployments, some countries such as Denmark, Greece, Switzerland, Sweden, or Australia, already show an effective coverage above 50% of their respective Internet populations, with others like the Netherlands or the United States slightly above 40%, mostly driven by few large ASes rather than many smaller ones.
Worldwide we observe a very low effective coverage of just 6.5% over the measured ASes, corresponding to 261 million end users currently safe from (malicious and accidental) route leaks, which means there’s still a long way to go before we can declare BGP to be safe.
…… 1https://rpki.cloudflare.com/ 2Gilad, Yossi, Avichai Cohen, Amir Herzberg, Michael Schapira, and Haya Shulman. "Are we there yet? On RPKI’s deployment and security." Cryptology ePrint Archive (2016). 3Geoff Huston. “Measuring ROAs and ROV”. https://blog.apnic.net/2021/03/24/measuring-roas-and-rov/ 4Measurements are issued stochastically when users encounter 1xxx error pages from default (non-customer) configurations. 5Probe requests are weighted by AS size as calculated from Cloudflare’s worldwide HTTP traffic. 6Quan, Lin, John Heidemann, and Yuri Pradkin. "When the Internet sleeps: Correlating diurnal networks with external factors." In Proceedings of the 2014 Conference on Internet Measurement Conference, pp. 87-100. 2014.
In this blog post, we’ll highlight a few stories from some of our 17 Employee Resource Groups (ERGs), including the most recent, Persianflare. But first, let me start with a personal story.
Do you remember being in elementary school and sitting in a classroom with about 30 other students when the teacher was calling on your classmates to read out loud from a book? The opportunity to read out loud was an exciting moment for many of my peers; one that made them feel proud of themselves. I, on the other hand, was frozen, in a state of panic, worried that I wouldn’t be able to sound out a word or completely embarrass myself by stuttering. I would practice reading the next paragraph in hopes that I wouldn’t mess up when I was called on. What I didn’t know at the time was that I was dyslexic, and I could barely read, especially out loud to a large group of people.
That is where I began to know the feeling of isolation. This feeling compounded year after year, when I wasn’t able to perform the way my peers did. My isolation prevailed from elementary school to middle school, through high school and even into college.
In college, I found a community that changed everything called Eye to Eye – a national non-profit organization that provides mentorship programs for students with learning disabilities. I attended one of their conferences with 200 other students. It was a profound moment when I realized that everyone in the room shared the experience of anxiety and fear around learning. Joining this community made me feel that I was not alone. Community for me is a group of people who have shared experience. Community allowed me to see my learning disability as an asset not a deficit. This is what I think the author, Nilofer Merchant, meant in the 11 Rules for Creating Value in the Social Era, when she said “The social object that unites people isn’t a company or a product; the social object that most unites people is a shared value or purpose.“
When I came to work at Cloudflare, I decided to become an ERG leader for Flarability, which provides a space for discussing disability and accessibility at Cloudflare. The same deep sense of community that I felt at Eye to Eye was available to me when I joined Flarability.
Globally, 85% of the company participates in ERGs and this year alone they hosted over 54 initiatives and events. As the pandemic persisted over the last year, Cloudflare remained a hybrid workforce which posed many challenges for our company culture. ERGs had to rethink the way they foster connection. Today, we are highlighting Persianflare, Afroflare, Greencloud and Desiflare because they have taken different approaches to building community.
Persianflare is our newest ERG, and in a very short amount of time, ERG Leader Shadnaz Nia has already brought together an entire community of folks who have created lasting impact. Here’s how…
Persianflare: Amplify the voice of Iranian people Shadnaz Nia, Solutions Engineer, Toronto
“Persianflare is the newest ERG which strives to nurture a community for all Persians and allies, where we perpetuate freedom of speech, proudly celebrate rich Persian heritage, appending growth and Persian convention. We have assembled with a desire to amplify the voice of the Iranian people, and bring awareness to human rights violations there, during unprecedented and unbearable times in history.
Cloudflare’s mission is to build a better Internet and one of our initiatives this year was to support building a better Internet that provides a more private Internet for the people of Iran. At Cloudflare, we are fortunate to have executive leadership that takes action and works tirelessly to provide more uncensored and accessible Internet in countries such as Iran. We’ve done this by offering WARP solutions in native Farsi language for all Persian-speaking users, empowering them to access uncensored information and news, in turn, strengthening the voice of Persian people living in Iran.
This project was accidentally routed to my team by the Product Team when they needed a translator. At the time, myself and other Persian employees were feeling powerless as a result of Mahsa Amini being murdered in the custody of the Iranian morality police. This was the birth of Persianflare. Through this project, I started collaborating with other employees and discovered that many of my colleagues really cared about this cause and wanted to help. Throughout the course of this initiative, we found more Persian employees in other regions and let them know about our progress. Words cannot describe how I felt when the app was released. It was one of the purest moments in my life. By bringing together Persian employees, allies of Persianflare, and the Product Team, this community was able to create real change for the people of Iran. To me, that is the power of community.
We plan to circle together to celebrate the global Human Rights Day on December 10, 2022, to continue discussing and growing our community. As the newest ERG, we are just getting started.”
“Afroflare is a community for People of African Diaspora to build connections while learning from each others’ lives, perspectives and experiences. Our initiatives in 2022 centered on creating and cultivating community by supporting and echoing Black voices and achievements within and outside of Cloudflare. Earlier in the year, given that the pandemic was slowing down but still active, we provided curated content that would allow members and allies to create, contribute and learn about cultures of the African diaspora at their own pace.
For our celebration of US Black History Month, we aggregated lists of Black-owned businesses and non-profit communities in various cities to support. We also hosted internal chats called “The Plug,” which highlight the immense talent of our members at Cloudflare. Lastly, Afroflare worked with allies to present an Allyship workshop called “Celebrating Black Joy- An Upskilling Session for Allies.”
As 2022 progressed, we shifted to a hybrid of in-person and virtual events in order to foster more interaction and strengthen bonds. Our celebration of UK Black History Month included a cross-culture party in our Lisbon office. We collaborated with Latinflare & Wineflare on an International Wine tasting event featuring South African wines, and an African + Caribbean food tasting event called “Taste from Home. We wrapped up the festivities with a Black Woman in Tech panel to discuss bias and how to navigate various obstacles faced by the BIPOC community in tech.
Virtually or in-person, this community has become a family – we laugh together, cry together, teach each other, and continue to grow together year after year. Each member’s experiences and culture are valued as we forge spaces for everyone to feel free to be authentic. Afroflare looks forward to continuing its goals of creating safe spaces, as well as educating, championing, and supporting our members and allies in 2023.”
Greencloud: A more sustainable Internet Annika Garbers, Product Manager, Georgia
“Greencloud is a coalition of Cloudflare employees who are passionate about the environment. Our vision is to address the climate crisis through an intersectional lens and help Cloudflare become a clear leader in sustainable practices among tech companies. Greencloud was initially founded in 2019 but experienced most of its growth in membership, engagement, and activities after the pandemic started. The group became an outlet for current and new employees to connect on shared passions and channel our COVID-fueled anxieties for the world into productive climate-focused action.
Greencloud’s organizing since 2020 has primarily centered around “two weeks of action.” The first is Impact Week (happening now!), which includes projects driven by Greencloud members to help our customers build a more sustainable Internet using Cloudflare products. The second is Earth Week, scheduled around the global Earth Day celebration in April, which focuses on awareness and education. We’ve leveraged the tools available to Cloudflare employees and our community, like our blog and Cloudflare TV, to share information with a broader audience and on a wider range of topics than would be possible with in-person events. This year, publicly available Earth Week programming included sessions about Cloudflare’s sustainability focus for our hardware lifecycle, an interview with a sustainability-focused Project Galileo participant, a Policy team overview of our sustainability reporting practices, and a conversation about sustainable transportation with our People team. Covering a wide range of topics throughout our events and content created by our members not only helps everyone learn something new, it also reminds us of the importance of embracing and encouraging diverse perspectives in every community. The diversity of the Greencloud collective is a small demonstration of the reality that climate change is only successfully addressed through holistic action by people with many outlooks and skills working together.
As we embrace more flexible modes of work, the Greencloud crew is looking forward to maintaining our virtual events as well as introducing more in-person opportunities to engage with each other and our local communities. Building and maintaining deep connections with each other is key to the momentum and sustainability(!) of this work in the long term.”
Desiflare: South Asian delights Arwa Ginwala, Solutions Engineering Manager, San Francisco
“Our goal for Desiflare is to build a sense of community among Cloudflare employees using the rich South Asian culture as a platform to bring people together. The Desiflare initiatives that had the most impact were in-person events after the two long years of pandemic. People were longing for a sense of community and belonging after months of Zoom fatigue. It was a fresh breath of air to see fellow Desis in person, across multiple Cloudflare offices. Folks hired during the pandemic got an opportunity to come visit the newly-renovated office in San Francisco. Desis enjoyed South Asian food at the Austin office for the first time since Desiflare’s inception. Diwali was celebrated in Singapore and Sydney offices, and the community in London played cricket, a sport very popular and well-loved in the South Asian community. Regardless of country of origin, gender, age or cultural beliefs, and in the presence of a competitive atmosphere, everyone shared and rejoiced with memories from their childhoods.
We realize that Desiflare members have different levels of comfort regarding meeting people in person or traveling for in-person events. But everyone wants to feel a sense of community and connection with people who share the same interests. Keeping this in mind, it was important to organize events where everyone felt included and had a chance to be part of the community based on their preferences. We met virtually for weekly chai time, monthly lunches, and are now organizing virtual jam sessions for many Desis to showcase their talent and enjoy South Asian music regardless of where they are located. The community has been most engaged on the Desiflare chat room. It has provided a platform for discussing common topics that help people feel supported. Desiflare gives a unique opportunity to employees to connect with their culture and roots regardless of their job title and team. It’s a way to network cross-functionally, and allows you to bring your whole self to work, which is one of the best things about working at Cloudflare.”
Conclusion
The ERGs at Cloudflare have helped us realize the power of community and how critical it is for hybrid work. What I have learned alongside our ERG leaders is that if we as individuals want to feel connected, understood and seen, our ERG communities are essential. You can check out all the incredible ERGs on the Life at Cloudflare page, and I encourage you to consider starting an ERG at your company.
Anyone who knows me knows that I am a proud member of the HBCU (Historically Black College or University) alumni. The HBCU Smart Cities Challenge invites all HBCUs across the United States to build technological solutions to solve real-world problems. When I learned that Cloudflare would be supporting the HBCU Smart Cities Challenge, I was on board immediately for so many personal reasons.
In addition to volunteering mentors as part of this partnership, Cloudflare offered HBCU Smart Cities the opportunity to apply for Project Galileo to protect and accelerate their online presence. Project Galileo provides free cyber security protection to free speech, public interest, and civil society organizations that are vulnerable to cyber attacks. After more than three years working at Cloudflare, I know that we can make the difference in bridging the gap in accessibility to the digital landscape by directly securing the Internet against today’s threats as well as optimizing performance, which plays a bigger role than most would think.
What is an HBCU?
A Historically Black College or University is defined as “any historically black college or university that was established prior to 1964, whose principal mission was, and is, the education of black Americans, and that is accredited by a nationally recognized accrediting agency or association determined by the Secretary of Education.” (Source: What is an HBCU? HBCU Lifestyle). I had the honor of graduating from the nation’s first degree-granting HBCU, Lincoln University of Pennsylvania.
One of the main reasons that I decided to attend a HBCU is that the available data suggests that HBCUs close the socioeconomic gap for Black students more than other high-education institutions (Source: HBCUs Close Socioeconomic Gap, Here’s How, 2021). This is exemplified by my own experience — I was a student that came from a low-income background, and became the first generation college graduate in my family. I believe it is due to HBCUs providing a united, supportive, and safe space for people from the African diaspora which equips us to be our best.
The HBCU Smart Cities Challenge
There are a wide range of problems the HBCU Smart Cities Challenge invites students to tackle. These problems include water management in Tuskegee, AL; broadband and security access in Raleigh, NC; public health for the City of Columbia, SC; and affordable housing in Winston-Salem, NC—just to name a few. Applying skills with smart technology to real-life problems helps improve upon the existing infrastructure in these cities.
To solve these problems, the challenge brings together students at HBCUs to build smart city applications. Over several months, developers, entrepreneurs, designers, and engineers will develop tech solutions using Internet of Things technology. In October, Cloudflare presented as part of a town hall in the HBCU Smart Cities series. We encouraged local leaders to think about using historic investments in broadband buildout to also lay the foundation for Smart Cities infrastructure at the same time. We described how, with solid infrastructure in place, the Smart Cities applications that are built on top of that infrastructure- would be fast, reliable, and secure — which is a necessity for infrastructure that residents rely on.
Here are some quotes from Norma McGowan Jackson, District 1 Councilwoman of City of Tuskegee and HBCU Smart City Fellow Arnold Bhebhe:
“As the council person for District 1 in the City of Tuskegee, which represents Tuskegee University, as the Council liaison for the HBCU Smart Cities Challenge, as a Tuskegee native, and as a Tuskegee Institute, (now University) alumnae, I am delighted to be a part of this collaboration. Since the days of Dr. Booker T. Washington, the symbiotic relationship between the Institute (now University) and the surrounding community has been acknowledged as critical for both entities and this opportunity to further enhance that relationship is a sure win-win!“ – Norma McGowan Jackson, District 1 Councilwoman of City of Tuskegee
“The HBCU Smart Cities Challenge has helped me to better understand that even though we live in an unpredictable world, our ability to learn and adapt to change can make us better innovators. I’m super grateful to have the opportunity to reinforce my problem-solving, creativity, and communication skills alongside like-minded HBCU students who are passionate about making a positive impact in our community.“ – Arnold Bhebhe,Junior at Alabama State University majoring in computer science
How Cloudflare helps
Attending an HBCU was one of the best decisions I have made in my life, and my motivation was seeing the product of HBCU graduates — noting that the first woman Vice President of the United States, Kamala Harris, is a HBCU graduate from Howard University.
The biggest honor for me is having the opportunity to build on the brilliance of these college students in this partnership, because I was in their shoes almost 25 years ago.
Further, to help protect websites associated with HBCU Smart Cities projects, Cloudflare has invited students in the program to apply for Project Galileo.
Finally, the HBCU Smart Cities Challenge are continually looking for mentors, sponsors and partnerships, as well as support and resources for the students. If you’re interested, please go here to learn more.
We mean a lot of things when we talk about helping to build a better Internet. Sometimes, it’s about democratizing technologies that were previously only available to the wealthiest and most technologically savvy companies, sometimes it’s about protecting the most vulnerable groups from cyber attacks and online prosecution. And the Internet does not exist in a vacuum.
As a global company, we see the way that the future of the Internet is affected by governments, regulations, and people. If we want to help build a better Internet, we have to make sure that we are in the room, sharing Cloudflare’s perspective in the many places where important conversations about the Internet are happening. And that is why we believe strongly in the value of public policy.
We thought this week would be a great opportunity to share Cloudflare’s principles and our theories behind policy engagement. Because at its core, a public policy approach needs to reflect who the company is through their actions and rhetoric. And as a company, we believe there is real value in helping governments understand how companies work, and helping our employees understand how governments and law-makers work. Especially now, during a time in which many jurisdictions are passing far-reaching laws that shape the future of the Internet, from laws on content moderation, to new and more demanding regulations on cybersecurity.
Principled, Curious, Transparent
At Cloudflare, we have three core company values: we are Principled, Curious, and Transparent. By principled, we mean thoughtful, consistent, and long-term oriented about what the right course of action is. By curious, we mean taking on big challenges and understanding the why and how behind things. Finally, by transparent, we mean being clear on why and how we decide to do things both internally and externally.
Our approach to public policy aims to integrate these three values into our engagement with stakeholders. We are thoughtful when choosing the right issues to prioritize, and are consistent once we have chosen to take a position on a particular topic. We are curious about the important policy conversations that governments and institutions around the world are having about the future of the Internet, and want to understand the different points of view in that debate. And we aim to be as transparent as possible when talking about our policy stances, by, for example, writing blogs, submitting comments to public consultations, or participating in conversations with policymakers and our peers in the industry. And, for instance with this blog, we also aim to be transparent about our actual advocacy efforts.
What makes Cloudflare different?
With approximately 20 percent of websites using our service, including those who use our free tier, Cloudflare protects a wide variety of customers from cyberattack. Our business model relies on economies of scale, and customers choosing to add products and services to our entry-level cybersecurity protections. This means our policy perspective can be broad: we are advocating for a better Internet for our customers who are Fortune 1000 companies, as well as for individual developers with hobby blogs or small business websites. It also means that our perspective is distinct: we have a business model that is unique, and therefore a perspective that often isn’t represented by others.
Strategy
We are not naive: we do not believe that a growing company can command the same attention as some of the Internet giants, or has the capacity to engage on as many issues as those bigger companies. So how do we prioritize? What’s our rule of thumb on how and when we engage?
Our starting point is to think about the policy developments that have the largest impact on our own activities. Which issues could force us to change our model? Cause significant (financial) impact? Skew incentives for stronger cybersecurity? Then we do the exercise again, this time, thinking about whether our perspective on that policy issue is dramatically different from those of other companies in the industry. Is it important to us, but we share the same perspective as other cybersecurity, infrastructure, or cloud companies? We pass. For example, while changing corporate tax rates could have a significant financial impact on our business, we don’t exactly have a unique perspective on that. So that’s off the list. But privacy? There we think we have a distinct perspective, as a company that practices privacy by design, and supports and develops standards that help ensure privacy on the Internet. And crucially: we think privacy will be critical to the future of the Internet. So on public policy ideas related to privacy we engage. And then there is our unique vantage point, derived from our global network. This often gives us important insight and data, which we can use to educate policymakers on relevant issues.
Our engagement channels
Our Public Policy team includes people who have worked in government, law firms and the tech industry before they joined Cloudflare. The informal networks, professional relationships, and expertise that they have built over the course of their careers are instrumental in ensuring that Cloudflare is involved in important policy conversations about the Internet. We do not have a Political Action Committee, and we do not make political contributions.
As mentioned, we try to focus on the issues where we can make a difference, where we have a unique interest, perspective and expertise. Nonetheless, there are many policies and regulations that could affect not only us at Cloudflare, but the entire Internet ecosystem. In order to track policy developments worldwide, and ensure that we are able to share information, we are members of a number of associations and coalitions.
Some of these advocacy groups represent a particular industry, such as software companies, or US based technology firms, and engage with lawmakers on a wide variety of relevant policy issues for their particular sector. Other groups, in contrast, focus their advocacy on a more specific policy issue.
In addition to formal trade association memberships, we will occasionally join coalitions of companies or civil society organizations assembled for particular advocacy purposes. For example, we periodically engage with the Stronger Internet coalition, to share information about policies around encryption, privacy, and free expression around the world.
It almost goes without saying that, given our commitment to transparency as a company and entirely in line with our own ethics code and legal compliance, we fully comply with all relevant rules around advocacy in jurisdictions across the world. You can also find us in transparency registers of governmental entities, where these exist. Because we want to be transparent about how we advocate for a better Internet, today we have published an overview of the organizations we work with on our website.
Shadow stacks are one of the methods employed to enforce control-flow
integrity and thwart attackers; they are a mechanism for fine-grained,
backward-edge protection. Most of the time, applications are not even
aware that shadow stacks are in use. As is so often the case, though, life
gets more complicated when the Checkpoint/Restore in Userspace
(CRIU) mechanism is in use. Not breaking CRIU turns out to be one of the
big challenges facing developers working to get user-space shadow-stack
support into the kernel.
Security updates have been issued by Debian (firefox-esr, libde265, php7.3, and thunderbird), Fedora (firefox, freeradius, freerdp, and xorg-x11-server), Oracle (firefox, prometheus-jmx-exporter, and thunderbird), Red Hat (firefox, nodejs:16, prometheus-jmx-exporter, and thunderbird), and SUSE (ceph and chromium).
The most recent iPhone update—to version 16.1.2—patches a zero-day vulnerability that “may have been actively exploited against versions of iOS released before iOS 15.1.”
Apple said security researchers at Google’s Threat Analysis Group, which investigates nation state-backed spyware, hacking and cyberattacks, discovered and reported the WebKit bug.
WebKit bugs are often exploited when a person visits a malicious domain in their browser (or via the in-app browser). It’s not uncommon for bad actors to find vulnerabilities that target WebKit as a way to break into the device’s operating system and the user’s private data. WebKit bugs can be “chained” to other vulnerabilities to break through multiple layers of a device’s defenses.
Проектът „Виртуален хайд парк „Гласът на младите” – стимулиране на гражданска активност сред украински младежи – бежанци в България” стартира в началото на м. септември 2022 г. Проектът се…
Amazon EMR Serverless is a serverless option in Amazon EMR that makes it easy for data analysts and engineers to run applications using open-source big data analytics frameworks such as Apache Spark and Hive without configuring, managing, and scaling clusters or servers. You get all the features of the latest open-source frameworks with the performance-optimized runtime of Amazon EMR, and without having to plan and operate instances and clusters.
With Amazon EMR, you can run your analytics applications on dedicated EMR clusters, on existing Amazon Elastic Kubernetes Service (Amazon EKS) clusters, or using the new EMR Serverless deployment option where you don’t have to manage clusters or instances. When you build a Spark or Hive application using an Amazon EMR release, say Amazon EMR 6.8, you can run the application on EMR clusters, on EKS clusters using Amazon EMR on EKS, or using EMR Serverless without having to change the application.
In this post, we discuss how you can estimate what it may cost to run an application that currently runs on EMR clusters using the new serverless option, and perform this analysis simply by using your current application metrics. This approach helps you evaluate and adopt the deployment option that is most cost effective for the application. However, the Amazon EMR pricing page doesn’t tell you how you can easily estimate the cost of running your existing EMR cluster applications on EMR Serverless. In the following sections, we describe an approach that enables you to do that.
Although the example in this post discusses how you can get a cost estimate for applications running on EMR clusters, you can also use the approach if you’re running a Spark or Hive application elsewhere, and want to estimate the cost of running it on EMR Serverless. For example, if you run self-managed Spark or Hive applications on Amazon Elastic Compute Cloud (Amazon EC2) clusters, or if you run Spark jobs on AWS Glue, we show you how you can use this approach to estimate the cost of running the application on EMR Serverless.
Estimating the cost of running applications on your EMR cluster
When you run applications on Amazon EMR clusters, you’re separately charged for the following:
The Amazon EC2 price of running cluster instances (the price for the underlying servers)
The total cost of running the cluster includes all three. There are a variety of Amazon EC2 pricing options you can choose from, including On Demand, 1-year and 3-year Reserved Instances, Capacity Savings Plans, and Spot Instances. The Amazon EC2 pricing option that you choose determines (a), the Amazon EC2 price. The cost of running the application on EMR clusters is the sum of (a), (b), and (c). You can compute this cost for the lifetime of running the cluster (from the time a cluster is started to the time the cluster is terminated), or for a specific period of time while the cluster is running. We recommend running the former, that is to compute (a), (b), and (c) from the time the cluster is started to the time the cluster is terminated. If you have set up tags for your Amazon EMR cluster, you can easily get the detailed cost report for your EMR cluster using AWS Cost Explorer.
Estimating the cost of running the same applications using EMR Serverless
When you run the same applications using EMR Serverless, you pay for the amount of vCPU, memory, and storage resources consumed by your applications. There is no separate charge for EC2 instances or EBS volumes. And, you only pay for the resources that are actually used by the application and not for EC2 instances provisioned. For example, when running applications on EMR clusters, when an EC2 instance in the cluster is partially utilized (say, 16 GB memory is used out of 64 GB available on the instance, or 4 VCPUs are utilized out of 16 VCPUs available on the instance), or when the EC2 instance is idle (for example, when the instance is initializing or waiting for an application to start), you still incur Amazon EC2, Amazon EMR, and Amazon EBS charges for the full EC2 instance and for the duration that the instance is active in the EMR cluster. With EMR Serverless, you only pay for the vCPU, memory, and storage resources used from the time workers start to run your Spark or Hive job until the time they stop.
To estimate the cost of running your EMR Spark or Hive application on EMR Serverless, you need to first aggregate the total compute vCore-seconds, memory MB-seconds, and storage GB-seconds consumed by each YARN application that ran on your EMR cluster, from the time the YARN container is started to the time the YARN container is terminated. You can obtain these metrics from YARN resource manager logs accessible from YARN timeline server or YARN CLI tools. You can retrieve the running time, vCore-seconds, and memory MB-seconds used by each of the YARN applications.
If your cluster only runs Spark applications, there is a simpler approach to estimate. Instead of obtaining the vCore-seconds, memory MB-seconds, and storage GB-seconds from YARN resource manager logs, you can obtain these metrics from Spark event logs. We have provided the tool EMR Servless Estimator, which can parse the Spark event logs for your applications and provide the aggregated metrics for your cost estimate.
After you get the usage metrics for your application, you can compute the estimated EMR Serverless cost using EMR Serverless pricing. Simply multiple your aggregated vCore-seconds with EMR Serverless vCPU pricing per second, multiply aggregated memory MB-seconds with the EMR Serverless memory pricing per second, and multiply storage GB-seconds with the EMR Serverless storage pricing per second (only if the storage requirements exceed 20 GB per worker). By adding up these costs for vCPU, memory, and storage, you can compare the cost of running the same applications on EMR Serverless.
In this approach, we assume that the performance of the application is equivalent. In other words, the size (vCPU, memory) and runtime duration for each YARN container on the EMR cluster is the same as the number, size, and runtime duration of workers needed to run the application on EMR Serverless. We make this assumption because the EMR runtime for an EMR release is the same regardless of whether the application is run on an EMR cluster or on EMR Serverless.
Example
Let’s do a sample cost comparison of Amazon EMR on EC2 and EMR Serverless using a single cluster.
We ran a Spark application on an EMR cluster with five nodes (one primary, two core, and two task and gathered YARN metrics using the YARN CLI. The following code shows our aggregate resource allocation.
We computed the Amazon EMR on EC2 costs as follows:
Cluster instances
Primary: m5.2xlarge:1
Core: r5.2xlarge:2
Task: r5.2xlarge:2
Cluster runtime = 18 min
Instance on-demand cost
m5.2xlarge (8 vCPU, 32 GiB memory)
Amazon EC2: $0.384/hr
Amazon EMR incremental: $0.096/hr
r5.2xlarge (8 vCPU, 64 GiB memory)
Amazon EC2: $0.504/hr
Amazon EMR incremental: $0.126/hr
The following is the EMR on EC2 cost calculation:
Amazon EMR cost = ((1 primary node x $0.096/hr) + (2 core nodes x $ 0.126/hr) + (2 task nodes x $0.126/hr)) = $0.60
Amazon EC2 cost = ((1 primary x $0.384 /hr ) + (2 core nodes x $0.504/hr) + (2 task nodes x $0.504/hr)) = $2.40
Amazon EMR on EC2 cluster cost/hr = $0.6 + $2.40 = $3/hr * 8/60 hr (runtime in hrs)
The total Amazon EMR on Amazon EC2 cost is $0.40/hr.
To calculate EMR Serverless cost, aggregate the vCore-seconds and memory MB-seconds for the same application you ran previously on the EMR cluster. Then multiply those numbers with the EMR Serverless vCPU and memory price. Our calculation results are as follows:
In this example, the total EMR Serverless cost is $0.231, a 42% reduction.
Conclusion
Amazon EMR Serverless is a recently launched serverless option in Amazon EMR that makes it easy to run open-source frameworks such as Spark and Hive without configuring, managing, and scaling clusters. Customers that already use EMR clusters want to understand how they can estimate the cost of running their EMR applications using EMR Serverless. We have presented an approach that you can use to conduct a cost analysis based on analyzing application metrics from your EMR clusters.
We hope you give this a try, and share your feedback with us!
About the authors
Radhika Ravirala is the Principal Product Manager at AWS.
Matthew Liem is the Senior Solution Architecture Manager at AWS.
Recent advances in ease of use and scalability have made streaming data easier to generate and use for real-time decision-making. Coupled with market forces that have forced businesses to react more quickly to industry changes, more and more organizations today are turning to streaming data to fuel innovation and agility.
Amazon Managed Streaming for Apache Kafka (MSK) is a fully managed service that makes it easy to build and run applications that use Apache Kafka, an open-source distributed event streaming platform designed for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. With Amazon MSK, you can capture real-time data from a wide range of sources such as database change events or web application user clickstreams. Since Kafka is highly optimized for writing and reading fresh data, it’s a great fit for operational reporting. However, gaining insight from this data often requires a specialized stream processing layer to write streaming records to a storage medium like Amazon S3, where it can be accessed by analysts, data scientists, and data engineers for historical analysis and visualization using tools like Amazon QuickSight.
When you want to analyze data where it lives and without developing separate pipelines and jobs, a popular choice is Amazon Athena. With Athena, you can use your existing SQL knowledge to extract insights from a wide range of data sources without learning a new language, developing scripts to extract (and duplicate) data, or managing infrastructure. Athena supports over 25 connectors to popular data sources including Amazon DynamoDB and Amazon Redshift which give data analysts, data engineers, and data scientists the flexibility to run SQL queries on data stored in databases running on-premises or in the cloud alongside data stored in Amazon S3. With Athena, there’s no data movement and you pay only for the queries you run.
What’s new
Starting today, you can now use Athena to query streaming data in MSK and self-managed Apache Kafka. This enables you to run analytical queries on real-time data held in Kafka topics and join that data with other Kafka topics as well as other data in your Amazon S3 data lake – all without the need for separate processes to first store the data on Amazon S3.
Solution overview
In this post, we show you how to get started with real-time SQL analytics using Athena and its connector for MSK. The process involves:
Registering the schema of your streaming data with AWS Glue Schema Registry. Schema Registry is a feature of AWS Glue that allows you to validate and reliably evolve streaming data against JSON schemas. It can also serialize data into a compressed format, which helps you save on data transfer and storage costs.
Creating a new instance of the Amazon Athena MSK Connector. Athena connectors are pre-built applications that run as serverless AWS Lambda applications, so there’s no need for standalone data export processes.
Using the Athena console to run interactive SQL queries on your Kafka topics.
Get started with Athena’s connector for Amazon MSK
In this section, we’ll cover the steps necessary to set up your MSK cluster to work with Athena to run SQL queries on your Kafka topics.
Prerequisites
This post assumes you have a serverless or provisioned MSK cluster set up to receive streaming messages from a producing application. For information, see Setting up Amazon MSK and Getting started using Amazon MSK in the Amazon Managed Streaming for Apache Kafka Developer Guide.
You’ll also need to set up a VPC and a security group before you use the Athena connector for MSK. For more information, see Creating a VPC for a data source connector. Note that with MSK Serverless, VPCs and security groups are created automatically, so you can get started quickly.
Define the schema of your Kafka topics with AWS Glue Schema Registry
To run SQL queries on your Kafka topics, you’ll first need to define the schema of your topics as Athena uses this metadata for query planning. AWS Glue makes it easy to do this with its Schema Registry feature for streaming data sources.
Schema Registry allows you to centrally discover, control, and evolve streaming data schemas for use in analytics applications such as Athena. With AWS Glue Schema Registry, you can manage and enforce schemas on your data streaming applications using convenient integrations with Apache Kafka. To learn more, see AWS Glue Schema Registry and Getting started with Schema Registry.
If configured to do so, the producer of data can auto-register its schema and changes to it with AWS Glue. This is especially useful in use cases where the contents of the data is likely to change over time. However, you can also specify the schema manually and will resemble the following JSON structure.
When setting up your Schema Registry, be sure to give it an easy-to-remember name, such as customer_schema, because you’ll reference it within SQL queries as you’ll see later on. For additional information on schema set up, see Schema examples for the AWS Glue Schema Registry.
Configure the Athena connector for MSK
With your schema registered with Glue, the next step is to set up the Athena connector for MSK. We recommend using the Athena console for this step. For more background on the steps involved, see Deploying a connector and connecting to a data source.
In Athena, federated data source connectors are applications that run on AWS Lambda and handle communication between your target data source and Athena. When a query runs on a federated source, Athena calls the Lambda function and tasks it with running the parts of your query that are specific to that source. To learn more about the query execution workflow, see Using Amazon Athena Federated Query in the Amazon Athena User Guide.
Start by accessing the Athena console and selecting Data sources on the left navigation, then choose Create data source:
Next, search for and select Amazon MSK from the available connectors and select Next.
In Data source details, give your connector a name, like msk, that’s easy to remember and reference in your future SQL queries. Under Connection details section, select Create Lambda function. This will bring you to the AWS Lambda console where you’ll provide additional configuration properties.
In the Lambda application configuration screen (not shown), you’ll provide the Application settings for your connector. To do this, you’ll need a few properties from your MSK cluster and schema registered in Glue.
On another browser tab, use the MSK console to navigate to your MSK cluster and then select the Properties tab. Here you’ll see the VPC subnets and security group IDs from your MSK cluster which you’ll provide in the SubnetIds and SecurityGroupIds fields in the Athena connector’s Application settings form. You can find the value for KafkaEndpoint by clicking View client information.
In the AWS Glue console, navigate to your Schema Registry to find the GlueRegistryArn for the schema you wish to use with this connector.
After providing these and the other required values, click Deploy.
Return to the Athena console and enter the name of the Lambda function you just created in the Connection details box, then click Create data source.
Run queries on streaming data using Athena
With your MSK data connector set up, you can now run SQL queries on the data. Let’s explore a few use cases in more detail.
Use case: interactive analysis
If you want to run queries that aggregate, group, or filter your MSK data, you can run interactive queries using Athena. These queries will run against the current state of your Kafka topics at the time the query was submitted.
Before running any queries, it may be helpful to validate the schema and data types available within your Kafka topics. To do this, run the DESCRIBE command on your Kafka topic, which appears in Athena as a table, as shown below. In this query, the orders table corresponds to the topic you specified in the Schema Registry.
DESCRIBE msk.customer_schema.orders
Now that you know the contents of your topic, you can begin to develop analytical queries. A sample query for a hypothetical Kafka topic containing e-commerce order data is shown below:
SELECT customer_id, SUM(order_total)
FROM msk.customer_schema.orders
GROUP BY customer_id
Because the orders table (and underlying Kafka topic) can contain an unbounded stream of data, the query above is likely to return a different value for SUM(order_total) with each execution of the query.
If you have data in one topic that you need to join with another topic, you can do that too:
SELECT t1.order_id, t2.item_id
FROM msk.customer_schema.orders as t1
JOIN msk.customer_schema.items as t2
ON t1.id = t2.id
Use case: ingesting streaming data to a table on Amazon S3
Federated queries run against the underlying data source which ensures interactive queries, like the ones above, are evaluated against the current state of your data. One consideration is that repeatedly running federated queries can put additional load on the underlying source. If you plan to perform multiple queries on the same source data, you can use Athena’s CREATE TABLE AS SELECT, also known as CTAS, to store the results of a SELECT query in a table on Amazon S3. You can then run queries on your newly created table without going back to the underlying source each time.
CREATE TABLE my_kafka_data
WITH (format = 'Parquet',
write_compression = 'SNAPPY')
AS
SELECT order_id, item_id, timestamp
FROM msk.customer_schema.orders
If you plan to do additional downstream analysis on this data, for example within dashboards on Amazon QuickSight, you can enhance the solution above by periodically adding new data to your table. To learn more, see Using CTAS and INSERT INTO for ETL and data analysis. Another benefit of this approach is that you can secure these tables with row-, column-, and table-level data governance policies powered by AWS Lake Formation to ensure only authorized users can access your table.
What else can you do?
With Athena, you can use your existing SQL knowledge to run federated queries that generate insights from a wide range of data sources without learning a new language, developing scripts to extract (and duplicate) data, or managing infrastructure. Athena provides additional integrations with other AWS services and popular analytics tools and SQL IDEs that allow you to do much more with your data. For example, you can:
Visualize the data in business intelligence applications like Amazon QuickSight
Design event-driven data processing workflows with Athena’s integration with AWS Step Functions
Unify multiple data sources to produce rich input features for machine learning in Amazon SageMaker
Conclusion
In this post, we learned about the newly released Athena connector for Amazon MSK. With it, you can run interactive queries on data held in Kafka topics running in MSK or self-managed Apache Kafka. This helps you bring real-time insights to dashboards or enable point-in-time analysis of streaming data to answer time-sensitive business questions. We also covered how to periodically ingest new streaming data into Amazon S3 without the need for a separate sink process. This simplifies recurring analysis of your data without incurring round-trip queries to your underlying Kafka clusters and makes it possible to secure the data with access rules powered by Lake Formation.
We encourage you to evaluate Athena and federated queries on your next analytics project. For help getting started, we recommend the following resources:
If you’re new to Athena and want to learn more about its features and capabilities, see Amazon Athena features.
Scott Rigney is a Senior Technical Product Manager with Amazon Web Services (AWS) and works with the Amazon Athena team based out of Arlington, Virginia. He is passionate about building analytics products that enable enterprises to make data-driven decisions.
Kiran Matty is a Principal Product Manager with Amazon Web Services (AWS) and works with the Amazon Managed Streaming for Apache Kafka (Amazon MSK) team based out of Palo Alto, California. He is passionate about building performant streaming and analytical services that help enterprises realize their critical use cases.
Currently, AWS Security Hub identifies controls and generates control findings in the context of security standards. Security Hub is aiming to release two new features in the first quarter of 2023 that will decouple controls from standards and streamline how you view and receive control findings.
The new features to be released are consolidated controls view and consolidated control findings. Consolidated controls view will provide you with a comprehensive view within the Security Hub console of your controls across security standards. This feature will also introduce a single unique identifier for each control across security standards.
Consolidated control findings will streamline your control findings. When this feature is turned on, Security Hub will produce a single finding for a security check even when a check is shared across multiple standards. This will reduce finding noise and help you focus on misconfigured resources in your AWS environment.
In this blog post, I’ll summarize the upcoming features, the benefit they bring to your organization, and how you can take advantage of them upon release.
Feature 1: Consolidated controls view
Currently, controls are identified, viewed, and managed in the context of individual security standards. In the Security Hub console, you first have to navigate to a specific standard to see a list of controls for that standard. Within the AWS Foundational Security Best Practices (FSBP) standard, Security Hub identifies controls by the impacted AWS service and a unique number (for example, IAM.1). For other standards, Security Hub includes the standard as part of the control identifier (for example, CIS 1.1 or PCI.AutoScaling.1).
After the release of consolidated controls view, you will be able to see a consolidated list of your controls from a new Controls page in the Security Hub console. Security Hub will also assign controls a consistent security control ID across standards. Following the current naming convention of the AWS FSBP standard, control IDs will include the relevant service and a unique number.
For example, the control AWS Config should be enabled is currently identified as Config.1 in the AWS FSBP standard, CIS 2.5 in the Center for Internet Security (CIS) AWS Foundations Benchmark v1.2.0, CIS 3.5 in the CIS AWS Foundations Benchmark v1.4.0, and PCI.Config.1 in the Payment Card Industry Data Security Standard (PCI DSS). After this release, this control will have a single identifier called Config.1 across standards. The single Controls page and consistent identifier will help you rapidly discover misconfigurations with minimal context-switching.
You’ll be able to enable a control for one or more enabled standards that include the control. You’ll also be able to disable a control for one or more enabled standards. As before, you can enable the standards that apply to your business case.
Changes to control finding fields and values after the release of consolidated controls view
After the release of consolidated controls view, note the following changes to control finding fields and values in the AWS Security Finding Format (ASFF).
ASFF field
What changes after consolidated controls view release
Example value before consolidated controls view release
Example value after consolidated controls view release
Compliance.SecurityControlId
A single control ID will apply across standards. ProductFields.ControlId will still provide the standards-based control ID.
Not applicable (new field)
EC2.2
Compliance.AssociatedStandards
Will show the standards that a control is enabled for.
Currently, multiple standards contain separate controls for the same security check. Security Hub generates a separate finding per standard for each related control that is evaluated by the same security check.
After release of the consolidated control findings feature, you’ll be able to unify control findings across standards and reduce finding noise. This, in turn, will help you more quickly investigate and remediate failed findings. When you turn on consolidated control findings, Security Hub will generate a single finding or finding update for each security check of a control, even if the check is shared across multiple standards.
For example, after you turn on the feature, you will receive a single finding for a security check of Config.1 even if you’ve enabled this control for the AWS FSBP standard, CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0, and PCI DSS. If you don’t turn on consolidated control findings, you will receive four separate findings for a security check of Config.1 if you’ve enabled this control for the AWS FSBP standard, CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0, and PCI DSS.
Changes to control finding fields and values after turning on consolidated control findings
If you turn on consolidated control findings, note the following changes to control finding fields and values in the ASFF. These changes are in addition to the changes previously described for consolidated controls view.
ASFF field
What changes after consolidated controls view release
Example value before consolidated controls view release
Example value after consolidated controls view release
New values for customer-provided finding fields after turning on consolidated control findings
When you turn on consolidated control findings, Security Hub will archive the existing findings and generate new findings. To view archived findings, you can visit the Findings page of the Security Hub console with the Record state filter set to ARCHIVED, or use the GetFindings API action. Updates you’ve made to the original finding fields in the Security Hub console or by using the BatchUpdateFindings API action will not be preserved in the new findings (if needed, you can recover this data by referring to the archived findings).
Note the following changes to customer-provided control finding fields when you turn on consolidated control findings.
Customer-provided ASFF field
Description of change after turning on consolidated control findings
Confidence
Will reset to empty state.
Criticality
Will reset to empty state.
Note
Will reset to empty state.
RelatedFindings
Will reset to empty state.
Severity
The default severity of the finding (matches the severity of the control).
Types
Will reset to standard-agnostic value.
UserDefinedFields
Will reset to empty state.
VerificationState
Will reset to empty state.
Workflow
New failed findings will have a default value of NEW. New passed findings will have a default value of RESOLVED.
How to turn consolidated control findings on and off
Follow these instructions to turn consolidated control findings on and off.
New accounts
If you enable Security Hub for an AWS account for the first time on or after the time when consolidated control findings is released, by default consolidated control findings will be turned on for your account. You can turn it off at any time. However, we recommend keeping it turned on to minimize finding noise.
If you use the Security Hub integration with AWS Organizations, consolidated control findings will be turned on for new member accounts if the administrator account has turned on the feature. If the administrator account has turned it off, it will be turned off for new subordinate AWS accounts (member accounts) as well.
Existing accounts
If your Security Hub account already existed before consolidated control findings is released, your account will have consolidated control findings turnedoff by default. You can turn it on at any time. We recommend turning it on to minimize finding noise. If you use AWS Organizations, consolidated control findings will be turned on or off for existing member accounts based on the settings of the administrator account.
To turn consolidated control findings on and off (Security Hub console)
In the navigation pane, choose Settings.
Choose the General tab.
For Controls, turn on Consolidated control findings. Turn it off to receive multiple findings for each standard.
Choose Save.
To turn consolidated control findings on and off (Security Hub API)
Run the UpdateSecurityHubConfiguration API action. Use the new ControlFindingGenerator attribute to change whether an account uses consolidated control findings:
To turn on consolidated control findings, set ControlFindingGenerator equal to SECURITY_CONTROL.
To turn it off, set ControlFindingGenerator equal to STANDARD_CONTROL.
To turn consolidated control findings on and off (AWS CLI)
In the AWS CLI, run the update-security-hub-configuration command. Use the new control-finding-generator attribute to change whether an account uses consolidated control findings:
To turn on consolidated control findings, set control-finding-generator equal to SECURITY_CONTROL.
To turn it off, set control-finding-generator equal to STANDARD_CONTROL.
API permissions for consolidated control findings
You’ll need AWS Identity and Access Management (IAM) permissions for the following new API operations in order for consolidated control findings to work as expected:
BatchGetSecurityControls – Returns account and Region-specific data about a batch of controls.
ListSecurityControlDefinitions – Returns information about controls that apply to a specified standard.
ListStandardsControlAssociations – Identifies whether a control is currently associated with or dissociated from each enabled standard.
BatchGetStandardsControlAssociations – For a batch of controls, identifies whether each control is currently associated with or dissociated from a specified standard.
BatchUpdateStandardsControlAssociations – Used to associate a control with enabled standards that include the control, or to dissociate a control from enabled standards. This is a batch substitute for the UpdateStandardsControl API action if an administrator doesn’t want to allow member accounts to associate or dissociate controls.
BatchGetControlEvaluations (private API) – Retrieves the enablement and compliance status of a control, the findings count for a control, and the overall security score for controls.
How to prepare for control finding field and value changes
If your workflows don’t rely on the specific format of any control finding fields, no action is required to prepare for the feature releases. We recommend that you immediately turn on consolidated control findings.
Consider waiting to turn on consolidated control findings if you currently rely on the Automated Security Response on AWS solution for predefined response and remediation actions. That solution does not yet support consolidated control findings. If you turn consolidated control findings on now, actions you deployed using the Automated Security Response solution will no longer work.
If you rely on the specific format of any control finding fields (for example, for custom automation), carefully review the upcoming finding field and value changes to ensure that your workflows will continue to function as intended. Note that the changes noted in the first table in this post might impact you if you rely on the specified control finding fields and values.
The changes noted in the second table and third table in this post will only impact you if you turn on consolidated control findings. For example, if you rely on ProductFields.ControlId, GeneratorId, or Title, you’ll be impacted if you turn on consolidated control findings. As another example, if you’ve created an Amazon CloudWatch Events rule that initiates an action for a specific control ID (such as invoking an AWS Lambda function if the control ID equals CIS 2.7), you’ll need to update the rule to use CloudTrail.2, the new Compliance.SecurityControlId field for that control.
If you’ve created custom insights by using the control finding fields or values that will change (see previous tables), we recommend updating those insights to use the new fields or values.
Conclusion
This post covered the control finding fields and values that will change in Security Hub after release of the consolidated controls view and consolidated control findings features. We recommend that you carefully review the changes and update your workflows to start using the new fields and values as soon as the features become available.
This post was co-written with Mike Zorn, Software Architect at LaunchDarkly as the lead author.
LaunchDarkly’s feature management platform enables customers to release features and measure their impact. As part of this platform, SDKs gather event data, and the event ingestion platform consumes and analyzes this data to measure impact. As the platform launched and customer adoption increased, we had to scale the event data pipeline to meet the demands of the business for new use cases that required zero data loss. We will explain the challenges that we ran into with the initial architecture and the advantages achieved by using Amazon Kinesis Data Streams and additional AWS services in the new architecture. We will also go into the different factors that we considered in the Amazon Kinesis Data Streams implementation for cost efficiency and performance.
Problem statement
LaunchDarkly’s mission is to fundamentally change how companies deliver software by helping them innovate faster, deploy fearlessly, and make each release a masterpiece. With LaunchDarkly, we allow customers to deploy when they want, release when they are ready, and get total control of the code to ship fast, reduce risk, and reclaim their nights and weekends.
In 2017, the event ingestion platform consisted of a fleet of web servers that would write events to several databases, as shown below, that stored event data to power several features of the LaunchDarkly product. These features allow LaunchDarkly’s customers to gain full visibility into how a feature is performing over time, optimize features through experimentation, and quickly verify their implementation. Unfortunately, all of the database writes to power these features were performed within a single process on these web servers, so if any one of these databases had an availability issue, events would queue up in memory until that process ran out of memory and crashed. Since that same database would be used to write data from each web server, all of them would eventually run out of memory and crash. This cycle would repeat itself until the database availability issue was rectified. During that time, there was a permanent loss of all of the event data that was sent by the SDKs.
The current system was tolerant of some data loss as the applications that used this data was limited. But the new features and workflows had stringer requirements on data-loss prevention.
We decided to explore alternatives where all the consumers are built with isolated fault tolerance, so each consumer is independent of one another in case of any issues. We built an event-driven pipeline that would be highly durable, scalable, and also provide the ability for data replay. As a result, we scaled from ingesting about 1 TB of data a day to more than 100 TBs of data now.
Mobile client using the LaunchDarkly SDK to evaluate feature flags
Application Load Balancer distributes traffic to Amazon EC2 nodes
Amazon EC2 nodes run a go application that writes traffic to Amazon Kinesis Data Streams
Amazon Kinesis Data Streams durably persist data
AWS Lambda writes various types of data to databases
Amazon OpenSearch Service records data about users
Amazon ElastiCache records data about flag statuses
Amazon Kinesis Firehose batches flag evaluation data and writes it to Amazon S3
Amazon S3 records data about flag evaluations
Data flows from a LaunchDarkly SDK into the events API, which is backed by an Application Load Balancer (ALB). That ALB routes traffic to a fleet of Amazon EC2 servers. Those servers persist the data to Amazon Kinesis Data Streams. Data is then read out of Amazon Kinesis Data Streams by Lambda functions that transform and write the data in different formats to several databases. The design has a few properties that were very important to this use case.
Durability
Isolation
Data replay
Durability would prevent data loss when issues in data processing arose. Isolation would prevent other consumers of data from failing when one consumer had a failure. Data replay would allow us to debug data anomalies and fix them retroactively.
Amazon Kinesis Data Streams satisfies these three properties. Data written to Amazon Kinesis Data Streams is persisted durably until the data ages out of the stream. Amazon Kinesis Data Streams allows for consumer isolation: each consumer maintains its own iterator position, so consumers can process data from a stream independently of one another. Finally, Amazon Kinesis Data Streams make data replay possible because consumers can set their shard iterator position to be in the past. For example, a consumer can be configured to start reading at 1 hour in the past if the last hour of data needs to be replayed.
A few additional technologies were considered that would allow us to achieve these design properties. Amazon Simple Notification Service (Amazon SNS) combined with Amazon Simple Queue Service (Amazon SQS) would allow for a system with durability and isolation. Data replay was not available out of the box and needed custom implementation to support this feature.
Apache Kafka was also considered, but in spite of the fact that it satisfies these design properties, it was not adopted because the team did not have prior experience with Apache Kafka. Amazon Kinesis Data Streams satisfies these design properties, and it is fully managed, which reduces the need to worry about a lack of operational expertise.
Amazon Kinesis Data Streams implementation deep dive
Before we started our Amazon Kinesis Data Streams implementation, during our initial proof-of-concept phase, we learned that although Amazon Kinesis Data Streams is fully managed, there are some aspects that need to be taken into consideration when implementing it at scale.
Costs
Client error handling
Amazon Kinesis Data Streams on-demand costs are proportional to the data volume put into the stream. However, if traffic is relatively even and predictable, provisioned throughput billing is more economical. Under provisioned throughput billing, customers also will be billed for put payloads, which is essentially an extra cost, especially if there are a number of small records. Since LaunchDarkly’s use case had predictable, even traffic, provisioned throughput was used. However, we had a small record size (about 100 bytes on average), so it was important to implement batching in order to control costs.
Kinesis Producer Library (KPL) supports a variety of languages, and if you use any of those, you can rely on that to efficiently batch records for you. However, since LaunchDarkly uses Go for backend applications, we had custom code because Go as a producer was not supported by KPL. Our solution was to batch data so that it was close to 25 kB (the size of a put payload). We did this by using protocol buffers and concatenating them together inside of a record.
Client errors occur when the application that writes to Amazon Kinesis Data Streams fails to write data successfully. These are important to minimize, and there are a few factors to consider to achieve that. First, design your application so that there are as few failure modes as possible in the final write path. In our application, we authenticate a request, check the value of some feature flags, and write the data to the Amazon Kinesis Data Stream. We optimized our code to not perform any database queries or network requests before the data is written to Amazon Kinesis Data Streams to avoid any query/call failures, which can cause data loss. Another step to implement is to increase the number of retries in the AWS SDK (we use 10). This way, if there’s a transient issue writing data to Amazon Kinesis Data Streams, the data will have a better likelihood of being persisted. Finally, having a coarse-grained rate limit is important if you’re using provisioned streams. Sometimes end producers will inadvertently configure an SDK to send incredible amounts of data to our system. In these scenarios, we have a rate limiter to prevent a single tenant from consuming too much of our provisioned capacity.
After we figured out how to address all these issues, we proceeded to migrate to the new architecture in two phases.
The first was to send our data into Amazon Kinesis Data Streams. The second was to move our consumer workload from our Amazon EC2 servers to AWS Lambda. For both of these phases, we used LaunchDarkly feature flag with a percentage rollout to gradually ramp up traffic to the new architecture.
The first phase, sending data to Amazon Kinesis Data Streams, went very smoothly. The batching mechanism worked as expected, and our throughput was also as expected. One thing that we had not expected was an increase in data transfer costs out of our virtual private cloud (VPC). By default, your Amazon Kinesis Data Streams traffic will go through your VPC’s network address translation (NAT) gateway. The charges are based on the data volume that flows through the NAT gateways. To reduce these costs, the design was optimized to configure a AWS Private Link endpoint in each Availability Zone where the Amazon EC2 application is hosted. This design optimization minimizes data transfer costs.
The second phase, moving the workload to AWS Lambda, did not go quite as smoothly. It turns out that dramatically changing the concurrency of a workload from tens of servers to hundreds of Lambda execution contexts can have some unintended consequences. In Amazon EC2, we aggregated our flag evaluation data on each host and flushed a file to Amazon S3 once a minute. In AWS Lambda, this aggregation became about 20 times less effective because of the increased concurrency. To overcome the issue of too many files for our downstream data processing systems to handle, we used Amazon Kinesis Data Firehose. We used it to automatically batch data into files in Amazon S3. Once we integrated that service into the architecture, we were able to migrate our entire workload to AWS Lambda.
Based on LaunchDarkly’s experience, Amazon Kinesis Data Streams are a good option for event data processing use cases. Once events are durably persisted in Amazon Kinesis Data Streams, stream consumers are easy to create, and event retention is managed for you. If you’re considering using Amazon Kinesis Data Streams, there are a few things you should account for in your implementation.
Configure AWS Private Link endpoints to reduce data transfer costs.
Use the KPL or implement your own record batching so that payloads are close to 25 kB.
Use rate limits to ensure you do not exceed provisioned capacity (if you aren’t using on-demand streams).
Increase retry counts to ensure data is written.
Conclusion
This system has been in production for over 3 years now, and we are very happy with it. It’s scaled from ingesting about 1 TB per day in 2018 to more than 100 TB per day now. Through that growth, this system has proven to be reliable, performant, and cost-effective. The system has maintained 99.99 percent availability and 99.99999 percent durability of data. End-to-end processing times have been within 30 s. Costs have scaled with increased usage, but they are well within our budget for this workload.
We hope that this post can guide you to build your event processing and analytics pipeline on top of Amazon Kinesis Data Streams while leveraging the power of fully managed technologies to not only accelerate business goals but also have a flexible system that onboards new use cases and features with ease.
About the Authors
Mike Zorn is a Software Architect at LaunchDarkly. He’s helped LaunchDarkly’s infrastructure scale from a hundred million feature flag evaluations a day to the tens of trillions of evaluations that are served nowadays. He’s been in the software industry for over a decade, working at organizations ranging from the federal government to small startups.
Chinmayi Narasimhadevara is a Solutions Architect focused on Analytics and Machine Learning at Amazon Web Services. She has over 15 years of experience in information technology. She helps AWS customers build advanced, highly scalable, and performant solutions.
Every so often, a family member or friend will ask me if an email they received is a phishing email. That’s part of my job as the unofficial family tech person. Email phishing and its cousins vishing (voice phishing) and smishing (text phishing), are still a serious problem for the average home computer user. While businesses are slowly implementing phishing detection tools—and, more importantly, user training—to help tackle the problem, home computer users are, for the most part, left to fend for themselves.
Our goal in this post is to provide a few tips and tricks for those oft-forgotten home computer users—your old-school neighbor, your unassuming grandma, or your friend who’s just not that tech savvy—in their effort to use their computer without losing their life savings by clicking on the wrong link.
You can scroll past the first few sections to the phishing tips we’ve prepared so that you can use to better understand and identify a phishing email. Or, continue reading to learn more about the phishing problem, why it matters, and then finish up with the phishing tips.
Why It Matters
Phishing is the use of social engineering techniques—tactics that use psychological manipulation like impersonating someone you know—to get you to take an action that can lead to your downloading a virus or malware, having your account credentials stolen, becoming an extortion victim, or some other malicious action.
While detection and blocking technology has advanced over the years, Dark Reading, a cyber security news site, estimates that up to one percent of all emails that make it to the end user’s mailbox are phishing emails. For home users, who typically have to rely on their internet service provider (referred to as an ISP) or their browser (like Chrome or Safari) to keep them safe, the number is probably higher. Still, 1% doesn’t sound like much—until you consider that to get to that point, these phishing emails are the best of the best. Suddenly, it starts to make sense as to why up to 70% of phishing emails are opened by the recipient.
Who Owns the Phishing Problem?
My friends and family are not creators or purveyors of technology; they are primarily users. Asking them to identify phishing emails by deciphering the email raw source or header is not in their wheelhouse, nor should it be. We take planes, trains, and automobiles without knowing much about how they work. It should be possible to safely receive and interact with an email without having to understand sender authentication or bone up on RFC 5322.
You as the family IT manager.
Back in 2005, when most of us first heard of phishing, we had a pretty good idea which businesses and people would contact us and how they would reach us. Today, nearly every company or organization we interact with has a website, an email subscription, an app, social media, and maybe a phone number or two. The daily number of messages we receive via email, phone, text, and so on has easily increased 10-fold (100-fold?) over that time. Do you really have any idea how many accounts you’ve created in your lifetime, and if so, how each of them reaches and interacts with you?
Making matters worse is the proliferation of data collection services—legitimate, shady, and illegal—which will sell personal information to nearly anyone with a purchase order, credit card, or better yet, the latest cryptocurrency. Personal data such as your name, address, last four digits of a credit card, and much more are readily available. As a result, a phishing email can use your name and provide additional personal details along the way in an effort to make you believe it is valid ← that’s social engineering at work.
What Can You Do?
For home computer users, the phishing problem may not be of your making, but you cannot rely on technology if you want to safely function in today’s highly connected world. Phishing uses some really crafty tactics (i.e. social engineering) to get you to believe that when you receive a message from the bad guys, it is okay to do what they are asking you to do. That means you have to be at your best when the incoming message chime rings.
To that end, below we’ve provided you with a little social engineering education in the form of some easy to remember tips you can use to ferret out a phish. We’ll use email in our examples, but the techniques can apply to most inbound communications you’ll receive. In addition, you don’t have to have any special technical superpowers, just some common sense and the ability to lower your FOMO (fear of missing out) threshold.
You can read the tips below, but we’ve also prepared a 20-minute Let’s Not Go Phishing Today webinar which provides a little more depth for each of these tips. You can read the tips below, watch the webinar, or both. The webinar is available on the Backblaze channel on BrightTALK. Keep in mind that you will need to register to watch.
Tip 1: No trust and not useful.
Situation
You receive an email from a business, organization, or person. You are certain you do not know or trust the sender and you were not expecting to receive the email.
Example
You receive an email to lower your mortgage interest rate from a bank you do not use. Oh, and you rent.
Considerations
There are zero reasons to open this email. There is no upside here at all for you. Even if this is not phishing, it is most likely spam.
Disposition
Delete the email while crooning, “But there ain’t no Coupe de Ville hiding at the bottom of a Cracker Jack box,” in the style of Meat Loaf (“Two Out of Three Ain’t Bad,” Bat Out of Hell, 1977).
Your on-stage moment is at 2:27.
Tip 2: No trust, but you’re not sure.
Okay, tip one was pretty simple. They get a little harder now.
Situation
You receive an email from a business, organization, or person. You might know the sender, but you really weren’t expecting an email.
Example
You receive an email and the sender name sounds familiar, but that’s it. Maybe you stopped by a store and provided your email to the clerk, maybe you bought a shirt from them two years ago, or maybe it’s just some advertisement you saw, but nothing is ringing a bell.
Considerations
Don’t open the email right away, let it sit in your inbox for a day or two to see if there is a follow up message or perhaps you remember something.
Often phishers will use time to pressure you into acting. Surely you would have remembered something so important, so don’t let time pressure you into doing something you shouldn’t. Trust yourself.
If you do open the email do not click on any of the links and do not call any phone numbers you may find in the email. Just read the email to see if anything jogs your memory.
Disposition
After a day or two, if nothing rings a bell, delete the email. If it was important, they’ll resend. Click delete.
If you think the email could be legit—Okay, really, just lower your FOMO threshold and click delete. I am sure that a bank in Ireland is not waiting to give you a million dollars if you call them.
Fun fact: $1 million in $1 bills weighs 1.1 tons. Say that three times fast!
Tip 3: Trust, but verify.
Situation
You receive an email from a business, organization, or person. You know the sender, but you weren’t really expecting an email from them.
Example
You receive a promotional email from a business. You are a customer of this business and even have an online account with them. You were not expecting the email, but the email makes you an offer that is interesting to you.
Considerations
You can receive promotional emails anytime, but they are more prevalent around holidays and marketing events like Cyber Monday. Phishers know this and will use this to their advantage to avoid detection.
A phisher can send out millions of emails in an attack spoofing a given business. If you have a relationship with that business, you are prime pickings. Do not assume that just because you are a customer, the email is legitimate.
A phisher can also send out very targeted emails using personal information they have collected from data breaches and other sources, both public and private. Just because an email has your name and other personal details, it does not mean it is legitimate.
If you decide to open the email do not click on any of the links and do not call any phone numbers you may find in the email. Read the email and see what they are asking you to do.
Disposition
If you think the promotional offer is legitimate, then open a new browser window and type in the URL to go to the website, or open the app on your phone/tablet for that business. You may have to sign in to your account, but the promotion should be available in one of those places. If the promotion is only available via the email, contact customer service for the business and ask. Remember to use the website or app to contact customer service, not any of the contact information provided in the email.
Sometimes, an offer is only available by clicking on a link in the email. In my opinion this is lazy marketing and puts you at risk. Let the business know this is not acceptable.
Spam or Phish?
The email described above could be just a spam email. Whether an email is spam or phishing can be confusing, but in general spam messages are just trying to sell you something and phishing emails have some harmful intent. That said, the same tips we are using for identifying a phishing email can be used to identify spam messages as well.
Tip 4: Trust, but still verify.
Situation
You receive an email from a business, organization, or person. You know the sender and you were expecting the email.
Example
You receive an email on the 10th of the month from your credit card company saying your statement is ready. They always send you this email on the 10th of the month. The email says you can click on the link to sign in to your account and view the statement.
Considerations
It is highly likely this is a legitimate email, but given this email concerns your financial affairs, being extra careful is imperative. Opening up a web browser and typing in the URL to go to the bank’s website to sign in there is safer. This also enforces the good behavior of not clicking on links in emails.
Many financial companies and health care providers are starting to maintain a list of messages they send you via email and/or text. You can log into your account to view the list to make sure that any message you received was actually sent by the provider—before you interact with the message. This is an excellent best practice and such businesses should be commended for thinking about their customer’s online safety and security.
Disposition
Even if you think the email is legitimate, use a web browser to access your online account, or use their app to take the requested action.
Downloading Email Attachments?
Only download an attachment that you were expecting to receive, preferably after you were notified via another email—or better yet another method such as a text message. For example, you or whomever you’re interacting with may say, “Hey Monique, I’m going to email those pictures in a minute.” Downloading unsolicited or unexpected attachments is not recommended.
Think of email, text messaging, and voicemail as read-only services, especially when it comes to your financial and health information. This is sometimes really hard with text messages that encourage you to “click this link to…” and voicemail messages saying “call us back at a specific number.” Such messages offer convenience and help move things forward—and sometimes, they are the only way to get things done. At that point, you have to trust the vendor and your instincts.
What to Do When You’re Forced to Click
There are two common situations where you are forced to click a link in an email or message in order to move forward: email newsletters and two factor (2FA) or multifactor (MFA) authentication.
We’re this happy about 2FA security too.
Newsletters
Newsletters can deliver valuable information and often link to other content for additional details. The trouble is, those links are often obscured by tracking redirects used to count how many clicks the link gets—It’s a marketing thing. The average user has little hope of figuring out where the link is actually going, so they are faced with ignoring the information or clicking to the unknown. Let’s break down an example.
Situation
You receive a newsletter from a company you do business with and have received newsletters from them before.
Example
Backblaze sends you a customer newsletter. There’s an article on a new feature and you want to learn more. To do so you have to click on a link, but when you rollover the link (don’t click) it reads something like: “https://hub.backblaze.com/xxt/XXt/R+000/xx-h-99/V88XHdW7_bXrN4b0ml7W7xsyK94Tmm-9N2x86z13q3phV1-WJV7CgHCJW7swZm-8j6kXwW6cD…” plus 50-60 more characters that are not displayed.
Considerations
It may seem it goes to the Backblaze website (backblaze.com), but without seeing the entire URL you can’t be sure. It could end with “.../bad-guys-website.com“, which would not take you to Backblaze.
Were you expecting this newsletter or at least have you gotten a newsletter from Backblaze before? If it is the first time, did you just sign up?
What is the intent of the newsletter? Providing information or asking for something? If the newsletter is asking you to sign in to your account for example, it is easy enough to open a new web browser window and sign in from there.
Disposition
This one is all about trust, timing, and clicks. Let’s assume you trust Backblaze as a good sender, the newsletter looks very Backblaze-y, and this is something you would expect. If you do click on the newsletter links, there are two primary things to consider.
First, if the link takes you to a sign up or sign in page, stop. Always open a new browser window, enter the URL to go to the site, and sign in from there.
Second, make sure the click takes you where you expected to go. If you get pop-ups for downloading a toolbar or extension, land on an unexpected webpage, or other unusual browser behavior (e.g. an automatic download), close the browser window and everything else on your system. Then, run a full antivirus scan immediately.
If you are not inclined to click on any links in newsletters, we understand. In our case most of the links on a Backblaze newsletter will go to our blog or our website. You can open a new browser window and find the content on the Backblaze website. This works for the many different newsletters you may get daily. That is: You can usually find the content directly versus clicking on the link.
Tell Us More…
The problem with not clicking on the links in newsletters and other similar communications is that marketing folks lose information about what is important to the recipients, but your peace of mind is more important. So, a healthy alternative is that you could send an email or post something on social media about what you like and what you don’t. Even visiting the pages and interacting with the articles the newsletter highlighted will help. Marketers get feedback, you give your opinion on good content, and you’re a little safer from phishing attacks.
2FA or MFA
More and more websites are requiring the use of two factor or multifactor authentication. Here are a couple of scenarios to help you deal with the messages you might receive.
Scenario 1
Situation
Your bank’s website uses text message-based two factor authentication to confirm access to your accounts.
Example
Using a browser, you log in to your bank’s website. A couple of seconds later, you receive the text on your phone with a code that you need to enter on the website.
Disposition
By asking to log in to your bank, you expect to get the text which provides the authentication code. You’re good.
Scenario 2
Situation
Your bank’s website uses two factor authentication to confirm access to your accounts. You believe it is text message-based authentication.
Example
Using a browser, you log in to your bank’s website. A couple of seconds later, you receive an email asking to click a link to allow the log in to your account.
Considerations
This is one of those cases where you need to know how the bank will contact you for the second factor. It could be a text message with the code (like the first example above). It could also be by clicking the link in a test message, or through an authentication app on your phone, or by email message, or even by phone.
Given the timing of the events in this example, it is highly likely that you had set up email as your second factor. But, sometimes it is not that easy to tell, especially if there are several minutes before you get the authentication message—or worse, if you don’t get the message at all.
One way to make this easier on you is to try to use the same authentication method for each website. The trouble is that different companies support different methods and not others. In some cases, you may be able to find information on the bank’s website to determine the authentication method they use.
Disposition
If you’re not sure of the authentication method that was set up, you can abandon the sign-in, then open a new browser window and start again. If you get the same authentication method, you can be reasonably confident you’re doing the right thing.
Moving Forward
Over the past couple of years, vendors involved with providing email, text, and voicemail services have gotten better at detecting and eliminating phishing, spam, and malware before it reaches you. That’s great. But the bad guys haven’t given up, and many would say they’ve gotten better.
These tips are a good starting point for improving your ability to stay safe using the internet, email, and your phone. There are many websites and resources where you can learn more and stay informed about phishing and other forms of malware. We listed a few below. You can click on the links, but (if you are a little paranoid at this point), you can search for “consumer phishing resources” or just “phishing resources” using your favorite search engine. Good luck, and stay safe.
Select Phishing Resources
Knowbe4: The world’s first and largest new-school security awareness training and simulated phishing platform.
Phishing.org: A project from KnowBe4 that is a resource for IT professionals to keep you up to date on the latest phishing threats. The Resources page has some free tools to help improve your phishing knowledge.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
