Correlate security findings with AWS Security Hub and Amazon EventBridge

Post Syndicated from Marshall Jones original https://aws.amazon.com/blogs/security/correlate-security-findings-with-aws-security-hub-and-amazon-eventbridge/

In this blog post, we’ll walk you through deploying a solution to correlate specific AWS Security Hub findings from multiple AWS services that are related to a single AWS resource, which indicates an increased possibility that a security incident has happened.

AWS Security Hub ingests findings from multiple AWS services, including Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS Firewall Manager, AWS Identity and Access Management (IAM) Access Analyzer, and AWS Systems Manager Patch Manager. Findings from each service are normalized into the AWS Security Finding Format (ASFF), so that you can review findings in a standardized format and take action quickly. You can use AWS Security Hub to provide a single view of all security-related findings, where you can set up alerting, automatic remediation, and ingestion into third-party incident management systems for specific findings.

Although Security Hub can ingest a vast number of integrations and findings, it cannot create correlation rules like a Security Information and Event Management (SIEM) tool can. However, you can create such rules using EventBridge. It’s important to take a closer look when multiple AWS security services generate findings for a single resource, because this potentially indicates elevated risk. Depending on your environment, the initial number of findings in AWS Security Hub findings may be high, so you may need to prioritize which findings require immediate action. AWS Security Hub natively gives you the ability to filter findings by resource, account, and many other details. With the solution in this post, when one of these correlated sets of findings is detected, a new finding is created and pushed to AWS Security Hub by using the Security Hub BatchImportFindings API operation. You can then respond to these new security incident-oriented findings through ticketing, chat, or incident management systems.

Prerequisites

This solution requires that you have AWS Security Hub enabled in your AWS account. In addition to AWS Security Hub, the following services must be enabled and integrated to AWS Security Hub:

Solution overview

In this solution, you will use a combination of AWS Security Hub, Amazon EventBridge, AWS Lambda, and Amazon DynamoDB to ingest and correlate specific findings that indicate a higher likelihood of a security incident. Each correlation is focused on multiple specific AWS security service findings for a single AWS resource.

The following list shows the correlated findings that are detected by this solution. The Description section for each finding correlation provides context for that correlation, the Remediation section provides general recommendations for remediation, and the Prevention/Detection section provides guidance to either prevent or detect one or more findings within the correlation. With the code provided, you can also add more correlations than those listed here by modifying the Cloud Development Kit (CDK) code and AWS Lambda code. The Solution workflow section breaks down the flow of the solution. If you choose to implement automatic remediation, each finding correlation will be created with the following AWS Security Hub Finding Format (ASFF) fields: 

- Severity: CRITICAL
- ProductArn: arn:aws:securityhub:<REGION>:<AWS_ACCOUNT_ID>:product/<AWS_ACCOUNT_ID>/default

These correlated findings are created as part of this solution:

  1. Any Amazon GuardDuty Backdoor findings and three critical common vulnerabilities and exposures (CVEs) from Amazon Inspector that are associated with the same Amazon Elastic Compute Cloud (Amazon EC2) instance.
    • Description: Amazon Inspector has found at least three critical CVEs on the EC2 instance. CVEs indicate that the EC2 instance is currently vulnerable or exposed. The EC2 instance is also performing backdoor activities. The combination of these two findings is a stronger indication of an elevated security incident.
    • Remediation: It’s recommended that you isolate the EC2 instance and follow standard protocol to triage the EC2 instance to verify if the instance has been compromised. If the instance has been compromised, follow your standard Incident Response process for post-instance compromise and forensics. Redeploy a backup of the EC2 instance by using an up-to-date hardened Amazon Machine Image (AMI) or apply all security-related patches to the redeployed EC2 instance.
    • Prevention/Detection: To mitigate or prevent an Amazon EC2 instance from missing critical security updates, consider using Amazon Systems Manager Patch Manager to automate installing security-related patching for managed instances. Alternatively, you can provide developers up-to-date hardened Amazon Machine Images (AMI) by using Amazon EC2 Image Builder. For detection, you can set the AMI property called ‘DeprecationTime’ to indicate when the AMI will become outdated and respond accordingly.
  2. An Amazon Macie sensitive data finding and an Amazon GuardDuty S3 exfiltration finding for the same Amazon Simple Storage Service (Amazon S3) bucket.
    • Description: Amazon Macie has scanned an Amazon S3 bucket and found a possible match for sensitive data. Amazon GuardDuty has detected a possible exfiltration finding for the same Amazon S3 bucket. The combination of these findings indicates a higher risk security incident.
    • Remediation: It’s recommended that you review the source IP and/or IAM principal that is making the S3 object reads against the S3 bucket. If the source IP and/or IAM principal is not authorized to access sensitive data within the S3 bucket, follow your standard Incident Response process for post-compromise plan for S3 exfiltration. For example, you can restrict an IAM principal’s permissions, revoke existing credentials or unauthorized sessions, restricting access via the Amazon S3 bucket policy, or using the Amazon S3 Block Public Access feature.
    • Prevention/Detection: To mitigate or prevent exposure of sensitive data within Amazon S3, ensure the Amazon S3 buckets are using least-privilege bucket policies and are not publicly accessible. Alternatively, you can use the Amazon S3 Block Public Access feature. Review your AWS environment to make sure you are following Amazon S3 security best practices. For detection, you can use Amazon Config to track and auto-remediate Amazon S3 buckets that do not have logging and encryption enabled or publicly accessible.
  3. AWS Security Hub detects an EC2 instance with a public IP and unrestricted VPC Security Group; Amazon GuardDuty unusual network traffic behavior finding; and Amazon GuardDuty brute force finding.
    • Description: AWS Security Hub has detected an EC2 instance that has a public IP address attached and a VPC Security Group that allows traffic for ports outside of ports 80 and 443. Amazon GuardDuty has also determined that the EC2 instance has multiple brute force attempts and is communicating with a remote host on an unusual port that the EC2 instance has not previously used for network communication. The correlation of these lower-severity findings indicates a higher-severity security incident.
    • Remediation: It’s recommended that you isolate the EC2 instance and follow standard protocol to triage the EC2 instance to verify if the instance has been compromised. If the instance has been compromised, follow your standard Incident Response process for post-instance compromise and forensics.
    • Prevention/Detection: To mitigate or prevent these events from occurring within your AWS environment, determine whether the EC2 instance requires a public-facing IP address and review the VPC Security Group(s) has only the required rules configured. Review your AWS environment to make sure you are following Amazon EC2 best practices. For detection, consider implementing AWS Firewall Manager to continuously audit and limit VPC Security Groups.

The solution workflow, shown in Figure 1, is as follows:

  1. Security Hub ingests findings from integrated AWS security services.
  2. An EventBridge rule is invoked based on Security Hub findings in GuardDuty, Macie, Amazon Inspector, and Security Hub security standards.
  3. The EventBridge rule invokes a Lambda function to store the Security Hub finding, which is passed via EventBridge, in a DynamoDB table for further analysis.
  4. After the new findings are stored in DynamoDB, another Lambda function is invoked by using Dynamo StreamSets and a time-to-live (TTL) set to delete finding entries that are older than 30 days.
  5. The second Lambda function looks at the resource associated with the new finding entry in the DynamoDB table. The Lambda function checks for specific Security Hub findings that are associated with the same resource.
Figure 1: Architecture diagram describing the flow of the solution

Figure 1: Architecture diagram describing the flow of the solution

Solution deployment

You can deploy the solution through either the AWS Management Console or the AWS Cloud Development Kit (AWS CDK).

To deploy the solution by using the AWS Management Console

In your account, launch the AWS CloudFormation template by choosing the following Launch Stack button. It will take approximately 10 minutes for the CloudFormation stack to complete.
Select the Launch Stack button to launch the template

To deploy the solution by using the AWS CDK

You can find the latest code in the aws-security GitHub repository where you can also contribute to the sample code. The following commands show how to deploy the solution by using the AWS CDK. First, the CDK initializes your environment and uploads the AWS Lambda assets to Amazon S3. Then, you can deploy the solution to your account. For <INSERT_AWS_ACCOUNT>, specify the account number, and for <INSERT_REGION>, specify the AWS Region that you want the solution deployed to.

cdk bootstrap aws://<INSERT_AWS_ACCOUNT>/<INSERT_REGION>

cdk deploy

Conclusion

In this blog post, we walked through a solution to use AWS services, including Amazon EventBridge, AWS Lambda, and Amazon DynamoDB, to correlate AWS Security Hub findings from multiple different AWS security services. The solution provides a framework to prioritize specific sets of findings that indicate a higher likelihood that a security incident has occurred, so that you can prioritize and improve your security response.

If you have feedback about this post, submit comments in the Comments section below. If you have any questions about this post, start a thread on the AWS Security Hub forum.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Marshall Jones

Marshall is a worldwide security specialist solutions architect at AWS. His background is in AWS consulting and security architecture, focused on a variety of security domains including edge, threat detection, and compliance. Today, he is focused on helping enterprise AWS customers adopt and operationalize AWS security services to increase security effectiveness and reduce risk.

Author

Jonathan Nguyen

Jonathan is a shared delivery team senior security consultant at AWS. His background is in AWS security, with a focus on threat detection and incident response. He helps enterprise customers develop a comprehensive AWS security strategy, deploy security solutions at scale, and train customers on AWS security best practices.

[$] Replacing congestion_wait()

Post Syndicated from original https://lwn.net/Articles/873672/rss

Memory management is a balancing act in a number of ways. The kernel must
balance the needs of current users of memory with anticipated future needs,
for example. The kernel must
also balance the act of reclaiming memory for other uses, which can involve
writing data to permanent storage, with the rate of data that the
underlying storage devices are able to accept. For years, the
memory-management subsystem has used storage-device congestion as a signal
that it should slow down reclaim. Unfortunately, that mechanism, which was
a bit questionable from the beginning, has not worked in a long time. Mel
Gorman is now trying to fix this problem with a
patch set that moves the kernel away from the idea of waiting on congestion.

Security updates for Monday

Post Syndicated from original https://lwn.net/Articles/873965/rss

Security updates have been issued by Debian (faad2 and mailman), Fedora (java-11-openjdk, libzapojit, nodejs, python-reportlab, vim, and watchdog), Mageia (ansible, docker-containerd, flatpak, tomcat, and virtualbox), openSUSE (containerd, docker, runc), Oracle (firefox and thunderbird), Red Hat (xstream), Scientific Linux (xstream), SUSE (cairo and containerd, docker, runc), and Ubuntu (apport and mysql-5.7, mysql-8.0).

Recog: Data Rules Everything Around Me

Post Syndicated from Matthew Kienow original https://blog.rapid7.com/2021/10/25/recog-data-rules-everything-around-me/

Recog: Data Rules Everything Around Me

The recog project — a recognition framework used to identify products, operating systems, and hardware through matching network probe data against its extensive fingerprint collection — has been around for many years. In the beginning, Rapid7 used it internally as part of the Nexpose vulnerability scanner. Then, in 2014, the fingerprints and Ruby implementation of the framework were released as open-source software, in keeping with Rapid7’s continued commitment to open-source initiatives. Later, in 2018, we released a Java implementation of the framework, recog-java, as open-source, and later that year, Rumble released a Go implementation of the framework, recog-go.

Still, there remained one problem to solve with the framework: balancing the roles of content and code. In recog, three different language implementations, with varying levels of feature parity, all support the most basic requirements of processing the XML fingerprint data, matching input data against the fingerprint collection and returning a collection of enrichment parameters, both static and dynamic. The value of these implementations (the code) isn’t fully realized without being combined with the fingerprint data (the content).

However, the Ruby implementation is clearly an outlier, since it stores the framework code alongside the fingerprint data. The problem of content versus code would not be as great of a concern if there were only one language implementation — but instead, we have three, and there have been recent conversations about the possibility of a fourth!

Solving the content vs. code conundrum

Carving off the Ruby implementation from the existing repository would leave the content while creating a consistent structure between all language implementations. Since this act would also remove the fingerprint testing performed by the Ruby implementation, it provides an opportunity to assess fingerprint verification across all recog implementations.

In the past, there were delayed reports of issues discovered between the different regular expression engines used in other language implementations after fingerprint pull requests were merged. Prevention required either the contributor or maintainer to verify fingerprint changes against the Java and Go implementations, and while the Go implementation has a verify tool, this was missing from Java.

In order to facilitate future content separation, the Java implementation would need a fingerprint verification tool. This was not as straightforward, since the Java library neither retained the data parsed from the fingerprint examples nor interpolated all parameters. But after some modifications to the `parse` and `match` methods, I was able to remove these impediments. I created an implementation of the recog fingerprint verification tool that matches both the features and behaviors of the Ruby tool as a new module within the Java implementation.

The final step is automation, which will allow contributors and maintainers to efficiently process fingerprint content changes and focus on the correctness of the regular expressions and enrichment parameters. This helps alleviate concerns around any issues with one or more of the language implementations.

I created a new GitHub Actions verify workflow for this purpose. The initial workflow simply runs the `recog_standardize` tool to ensure each fingerprint asserts known identifiers. The latest update to the workflow adds jobs, in which each language implementation’s fingerprint verification tool runs against any updated fingerprint XML files. The verify workflow provides necessary feedback to contributors and maintainers, improving the content modification process.

Recog: Data Rules Everything Around Me
View of successful verify workflow

These steps are the first of more to come that will aid users, contributors, and maintainers of the recog recognition framework project. Recog content and language implementations form a component within other projects in the information security domain.

Recog is often used as a component in large projects, and we have plans for additional tooling to make the framework more directly usable for end users. As recog develops and grows, the Rapid7 team looks forward to watching projects built on top of it develop and grow.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Cloudflare Tunnel for Content Teams

Post Syndicated from Alice Bracchi original https://blog.cloudflare.com/cloudflare-tunnel-for-content-teams/

Cloudflare Tunnel for Content Teams

Cloudflare Tunnel for Content Teams

A big part of the job of a technical writer is getting feedback on the content you produce. Writing and maintaining product documentation is a deeply collaborative and cyclical effort — through constant conversation with product managers and engineers, technical writers ensure the content is clear and serves the user in the most effective way. Collaboration with other technical writers is also important to keep the documentation consistent with Cloudflare’s content strategy.

So whether we’re documenting a new feature or overhauling a big portion of existing documentation, sharing our writing with stakeholders before it’s published is quite literally half the work.

In my experience as a technical writer, the feedback I’ve received has been exponentially more impactful when stakeholders could see my changes in context. This is especially true for bigger and more strategic changes. Imagine I’m changing the structure of an entire section of a product’s documentation, or shuffling the order of pages in the navigation bar. It’s hard to guess the impact of those changes just by looking at the markdown files.

We writers check those changes in context by building a development server on our local machines. But sharing what we see locally with our stakeholders has always been a pain point for us. We’ve sent screenshots (hardly a good idea). We’ve recorded our screens. We’ve asked stakeholders to check out our branches locally and build a development server on their own. Lately, we’ve added a GitHub action to our open-source cloudflare-docs repo that allows us to generate a preview link for all pull requests with a certain label. However, that requires us to open a pull request with our changes, and that is not ideal if we’re documenting a feature that’s yet to be announced, or if our work is still in its early stages.

So the question has always been: could there be a way for someone else to see what we see, as easily as we see it?

Enter Cloudflare Tunnel

I was working on a complete refresh of Cloudflare Tunnel’s documentation when I realized the product could very well answer that question for us as a technical writing team.

If you’re not familiar with the product, Cloudflare Tunnel provides a secure way to connect your local resources to the Cloudflare network without poking holes in your firewall. By running cloudflared in your environment, you can create outbound-only connections to Cloudflare’s edge, and ensure all traffic to your origins goes through Cloudflare and is protected from outside interference.

For our team, Cloudflare Tunnel could offer a way for our stakeholders to interact with what’s on our local environments in real-time, just like a customer would if the changes were published. To do that, we could expose our local environment to the edge through a tunnel, assign a DNS record to that tunnel, and then share that URL with our stakeholders.

So if each member in the technical writing team had their own tunnel that they could spin up every time they needed to get feedback, that would pretty much solve our long-standing problem.

Cloudflare Tunnel for Content Teams

Setting up the tunnel

To test out that this would work, I went ahead and tried it for myself.

First, I made sure to create a local branch of the cloudflare-docs repo, make local changes, and run a development server locally on port 8000.

Since I already had cloudflared installed on my machine, the next thing I needed to do was log into my team’s Cloudflare account, pick the zone I wanted to create tunnels for (I picked developers.cloudflare.com), and authorize Cloudflare Tunnel for that zone.

$ cloudflared login

Next, it was time to create the Named Tunnel.

$ cloudflared tunnel create alice
Tunnel credentials written to /Users/alicebracchi/.cloudflared/0e025819-6f12-4f49-8183-c678273feef4.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.

Created tunnel alice with id 0e025819-6f12-4f49-8183-c678273feef4

Alright, tunnel created. Next, I needed to assign a DNS record to it. I wanted it to be something readable and easily shareable with stakeholders (like abracchi.developers.cloudflare.com), so I ran the following command and specified the tunnel name first and then the desired subdomain:

$ cloudflared tunnel route dns alice abracchi

Next, I needed a way to tell the tunnel to serve traffic to my localhost:8000 port. For that, I created a configuration file in my default cloudflared directory and specified the following fields:

url: https://localhost:8000
tunnel: 0e025819-6f12-4f49-8183-c678273feef4
credentials-file: /Users/alicebracchi/.cloudflared/0e025819-6f12-4f49-8183-c678273feef4
.json

Time to run the tunnel. The following command established connections between my origin and the Cloudflare edge, telling the tunnel to serve traffic to my origin according to the parameters I’d specified in the config file:

$ cloudflared tunnel --config /Users/alicebracchi/.cloudflared/config.yml run alice
2021-10-18T09:39:54Z INF Starting tunnel tunnelID=0e025819-6f12-4f49-8183-c678273feef4
2021-10-18T09:39:54Z INF Version 2021.9.2
2021-10-18T09:39:54Z INF GOOS: darwin, GOVersion: go1.16.5, GoArch: amd64
2021-10-18T09:39:54Z INF Settings: map[cred-file:/Users/alicebracchi/.cloudflared/0e025819-6f12-4f49-8183-c678273feef4.json credentials-file:/Users/alicebracchi/.cloudflared/0e025819-6f12-4f49-8183-c678273feef4.json url:http://localhost:8000]
2021-10-18T09:39:54Z INF Generated Connector ID: 90a7e3a9-9d59-4d26-9b87-4b94ebf4d2a0
2021-10-18T09:39:54Z INF cloudflared will not automatically update when run from the shell. To enable auto-updates, run cloudflared as a service: https://developers.cloudflare.com/argo-tunnel/reference/service/
2021-10-18T09:39:54Z INF Initial protocol http2
2021-10-18T09:39:54Z INF Starting metrics server on 127.0.0.1:64193/metrics
2021-10-18T09:39:55Z INF Connection 13bf4c0c-b35b-4f9a-b6fa-f0a3dd001951 registered connIndex=0 location=MAD
2021-10-18T09:39:56Z INF Connection 38510c22-5256-45f2-abf8-72f1207ca242 registered connIndex=1 location=LIS
2021-10-18T09:39:57Z INF Connection 9ab0ea06-b1cf-483c-bd48-64a067a87c39 registered connIndex=2 location=MAD
2021-10-18T09:39:58Z INF Connection df079efe-8246-4e93-85f5-10caf8b7c354 registered connIndex=3 location=LIS

And sure enough, at abracchi.developers.cloudflare.com, my teammates could see what I was seeing on localhost:8000.

Securing the tunnel

After creating the tunnel, I needed to make sure only people within Cloudflare could access that tunnel. As it was, anyone with access to abracchi.developers.cloudflare.com could see what was in my local environment. To fix this, I set up an Access self-hosted application by navigating to Access > Applications on the Teams Dashboard. For this application, I then created a policy that restricts access to the tunnel to a user group that includes only Cloudflare employees and requires authentication via Google or One-time PIN (OTP).

This makes applications like my tunnel easily shareable between colleagues, but also safe from potential vulnerabilities.

Cloudflare Tunnel for Content Teams

Et voilà!

Back to the Tunnels page, this is what the content team’s Cloudflare Tunnel setup looks like after each writer completed the process I’ve outlined above. Every writer has their personal tunnel set up and their local environment exposed to the Cloudflare Edge:

Cloudflare Tunnel for Content Teams

What’s next

The team is now seamlessly sharing visual content with their stakeholders, but there’s still room for improvement. Cloudflare Tunnel is just the first step towards making the feedback loop easier for everyone involved. We’re currently exploring ways we can capture integrated feedback directly at the URL that’s shared with the stakeholders, to avoid back-and-forth on separate channels.

We’re also looking into bringing in Cloudflare Pages to make the entire deployment process faster. Stay tuned for future updates, and in the meantime, check out our developer docs.

THE VENEZUELA LAUNDROMAT Maduro’s treasurer extradited to USA, specialised prosecutors drag their feet over his money at Bulgaria’s Investbank

Post Syndicated from Николай Марченко original https://bivol.bg/maduros-treasurer-extradited-to-usa-specialised-prosecutors-drag-their-feet-over-his-money-at-bulgarias-investbank.html

понеделник 25 октомври 2021


Over the past weekend Colombian billionaire Alex Saab Moran, appointed by Venezuelan dictator Nicolas Maduro as his “special diplomatic envoy”, was extradited from Cabo Verde to the USA, where he…

Кво са някакви си половин милиард за нашия Северозапад!?

Post Syndicated from original https://bivol.bg/%D0%BA%D0%B2%D0%BE-%D1%81%D0%B0-%D0%BD%D1%8F%D0%BA%D0%B0%D0%BA%D0%B2%D0%B8-%D1%81%D0%B8-%D0%BF%D0%BE%D0%BB%D0%BE%D0%B2%D0%B8%D0%BD-%D0%BC%D0%B8%D0%BB%D0%B8%D0%B0%D1%80%D0%B4-%D0%B7%D0%B0-%D0%BD%D0%B0.html

понеделник 25 октомври 2021


Едва ли нужно да припомняме как услужливите медии тичаха след Бойко да го снимат, докато се пъчи и гледа решително, режейки лентички на обекти, които влизаха в ремонт само след…

Celebrate CoderDojo’s 10th birthday with us!

Post Syndicated from Zoë Kinstone original https://www.raspberrypi.org/blog/coderdojo-10th-birthday/

We are inviting you all to a very special event this week: the CoderDojo team is hosting a 10th birthday livestream to celebrate the CoderDojo community and all that they have achieved over the last ten years.

Everyone is welcome, so mark your diary and make sure you and your favourite young coders join us for all the fun at 18:00 BST this Thursday, 28 October! 

Together we will hear stories from young people and volunteers around the world, and from James Whelton and Bill Liao, the co-founders of CoderDojo.

Ten years of community spirit

In July 2011, James Whelton and Bill Liao held the first-ever CoderDojo session in Cork, Ireland. They created a space for young people to learn how to create a website, design a game, or write their first program. The session was also a chance for volunteers to share their experience and time with a younger generation and their peers. It was here that the CoderDojo grassroots community came into existence, built on the values of ‘being cool’: creativity, collaboration, openness, and fun.

A Dojo session in Ireland.

These values continue to inspire young people (Ninjas) and volunteers around the world to be part of their local Dojos. In 2017, the CoderDojo Foundation, which was founded to support the CoderDojo movement, and the Raspberry Pi Foundation joined forces to better support the community to bring opportunities to more young people worldwide.

A man helps four young people to code projects at laptops in a CoderDojo session.
A Dojo session in Uganda.

The tenth year of the movement is an especially important time for us to celebrate the volunteers who have put so much into CoderDojo. As well as the livestream celebration on 28 October, the CoderDojo team has put together free digital assets to get volunteers and Ninjas in the birthday spirit, and a special birthday giveaway for Ninjas who are coding projects to mark this momentous anniversary.

Three young people learn coding at laptops supported by a volunteer at a CoderDojo session.
A CoderDojo session in India.

Ten things we love about you

In celebration of the CoderDojo movement’s 10th birthday, here’s a list of some of our favourite things about the CoderDojo community.  

1. You are always having so much fun!

Whether you’re working together in person or online, you are always having a blast!

  • A tweet about CoderDojo.

2. You are resilient and committed to your club 

The pandemic has been an extremely difficult time for Dojos. It has also been a time of adaptation. We have been so impressed by how community members have switched their ways of running with positivity and commitment to 6. do what is best for their clubs.

A tweet about CoderDojo.

3. You support each other

Every day, Dojo volunteers support each other locally and globally to sustain the movement and help Ninjas learn — from sharing how they run sessions when social distancing is necessary, to translating online resources and web pages so that more people around the world can join the CoderDojo community.

“We know that we’re not out there alone, that there’s a whole world of people who are all collaborating with the same mission in mind is really thrilling as well.”

Nikole Vaughn, CoderDojo Collaborative in San Antonio, Texas

4. You tell the team how to support you 

Filling in surveys, emailing the CoderDojo team here, attending webinars, sharing your insights — these are all the ways you’re great at communicating your Dojo’s needs. We love supporting you!

5. You help young people create positive change in their community 

We love to hear about how CoderDojo volunteers help young people to create and learn with technology, and to become mentors for their peers. Recently we shared the stories of Avye, Laura, and Toshan, three incredible digital makers who, thanks to CoderDojo, are using technology to shape the world around them.

Laura, teenage roboticist and CoderDojo Ninja, with and-Catherine Grace Coleman.
Laura says, “I joined my local CoderDojo, and it changed my life.”

6. You love a challenge

From coding for the CoderDojo 10th birthday giveaway to the European Astro Pi Challenge, CoderDojo members love to put themselves to the test!   

7. You brought Coolest Projects into the world 

Coolest Projects is the world-leading technology fair for young people, and it originated in the CoderDojo community!

The crowd at a Coolest Projects event.

This year, in its ninth year running, Coolest Projects again was a platform for fantastic tech projects from Ninjas, including an AI bicycle app and a glove that makes music.

8. You are committed to creating inclusive spaces 

CoderDojo is a space for everyone to create and learn with technology. We love that Dojos get involved in projects such as the ‘Empowering the future’ guide to getting more girls involved in coding, and the CoderDojo Accessibility Guide to making Dojo sessions accessible for young people of all abilities and neurodiversity.

A tweet about CoderDojo.

9. You are a community that continues to grow stronger

Over the last ten years, more than 3900 Dojos in 115 countries have run sessions for over 270000 young people and have been regularly supporting 100000 young coders! You’ve certainly brought the movement a long way from that very first session in Cork.   

10. You are simply the best grassroots community on the planet! 

All the volunteers who have put their time and energy into CoderDojo have made the movement what it is today, and we’d like to say a massive thank you to each and every one of you.

A clip of David Bowie pointing at the viewer and saying 'you', with overlayed text 'you're the best'.

Let’s celebrate together! 

So prepare your favourite celebratory food and join us for the birthday livestream on Thursday 28 October at 18:00 BST! Take this chance to say hi to community members and celebrate everything that they have achieved in the last ten years.

Set a reminder for the livestream, and tell us how you are celebrating CoderDojo’s 10th birthday using the hashtag #10YearsOfCoderDojo on Twitter. 

The post Celebrate CoderDojo’s 10th birthday with us! appeared first on Raspberry Pi.

Review: Dune (2021)

Post Syndicated from original https://blog.erratasec.com/2021/10/review-dune.html

One of the most important classic sci-fi stories is the book “Dune” from Frank Herbert. It was recently made into a movie. I thought I’d write a quick review.

The summary is this: just read the book. It’s a classic for a good reason, and you’ll be missing a lot by not reading it.

But the movie Dune (2021) movie is very good. The most important thing to know is see it in IMAX. IMAX is this huge screen technology that partly wraps around the viewer, and accompanied by huge speakers that overwhelm you with sound. If you watch it in some other format, what was visually stunning becomes merely very pretty.

This is Villeneuve’s trademark, which you can see in his other works, like his sequel to Bladerunner. The purpose is to marvel at the visuals in every scene. The story telling is just enough to hold the visuals together. I mean, he also seems to do a good job with the story telling, but it’s just not the reason to go see the movie. (I can’t tell — I’ve read the book, so see the story differently than those of you who haven’t).

Beyond the story and visuals, many of the actor’s performances were phenomenal. Javier Bardem’s “Stilgar” character steals his scenes. Stellan Skarsgård exudes evil. The two character actors playing the mentats were each perfect. I found the lead character (Timothée Chalamet) a bit annoying, but simply because he is at this point in the story.

Villeneuve’s splits the book into two parts. This movie is only the first part. This presents a problem, because up until this point, the main character is just responding to events, not the hero who yet drives the events. It doesn’t fit into the traditional Hollywood accounting model. I really want to see the second film even if the first part, released in the post-pandemic turmoil of the movie industry, doesn’t perform well at the box office.

In short, if you haven’t read the books, I’m not sure how well you’ll follow the storytelling. But the visuals (seen at IMAX scale) and the characters are so great that I’m pretty sure most people will enjoy the movie. And go see it on IMAX in order to get the second movie made!!

The collective thoughts of the interwebz