Post Syndicated from Биволъ original https://bivol.bg/proekt-ukrainci.html
С поредица от информационни дни приключи проектът „Виртуален хайд парк „Гласът на младите” – стимулиране на гражданска активност сред украински младежи – бежанци в България”. Проектът бе изпълнен от Сдружение…
Post Syndicated from Emily Flannery original http://blog.cloudflare.com/star-your-favorite-websites-in-the-dashboard/
We’re excited to introduce starring, a new dashboard feature built to speed up your workflow. You can now “star” up to 10 of the websites and applications you have on Cloudflare for quicker access.
We have heard from many of our users, particularly ones with tens to hundreds of websites and applications running on Cloudflare, about the need to “favorite” the ones they monitor or configure most often. For example, domains or subdomains that our users designate for development or staging may be accessed in the Cloudflare dashboard daily during a build, migration or a first-time configuration, but then rarely touched for months at a time; yet every time logging in, these users have had to go through multiple steps—searching and paging through results—to navigate to where they need to go. These users seek a more efficient workflow to get to their destination faster. Now, by starring your websites or applications, you can have easier access.
Today, you can star up to 10 items per account. Simply star a website or application you have added to Cloudflare from its Overview page. Once you have starred at least one item, you will then see these marked as “starred” in most places across the dashboard. Just look for the yellow star icon. You can always remove from starred by toggling the button.
By starring a website or application, you can then filter your lists down to display starred items only. To do so, simply select the “starred” filter from the Home page or the site switcher from the sidebar navigation.
Try it out for yourself—log into your account to get started today.
We're very excited to offer this new functionality for better organization of your Cloudflare experience, and about the many possibilities to mature this feature. After trying it out, give us a shout in the Cloudflare Community to let us know what improvements you’d like to see come next.
Post Syndicated from Rapid7 original https://blog.rapid7.com/2023/08/24/why-your-aws-cloud-container-needs-client-side-security/
With increasingly complicated network infrastructure and organizations needing to deploy applications across various environments, cloud containers are necessary for companies to stay agile and innovative. Containers are packages of software that hold all of the necessary components for an app to run in any environment. One of the biggest benefits of cloud containers? They virtualize an operating system, enabling users to access from private data centers, public clouds, and even laptops.
According to recent research by Faction, 92% of organizations have a multi-cloud strategy in place or are in the process of adopting one. In addition to the ubiquity of cloud computing, there are a variety of cloud container providers, including Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure. Nearly 80% of all containers on the cloud, however, run on AWS, which is known for its security, reliability, and scalability.
When it comes to cloud container security, AWS works on a shared responsibility model. This means that security and compliance is shared between AWS and the client. AWS protects the infrastructure running the services offered in the cloud — the hardware, software, networking, and facilities.
Unfortunately, many AWS users stop here. They believe that the security provided by AWS is sufficient to protect their cloud containers. While it is true that the level of customer responsibility for security differs depending on the AWS product, each product does require the customer to assume some level of security responsibility.
To avoid this mistake, let’s examine why your AWS cloud container needs additional client-side security and how Rapid7 can help.
Some of the same qualities that make containers ideal for agility and innovation also creates difficulty in visibility and monitoring. Cloud containers are ephemeral, which means they’re easy to establish and destroy. This is convenient for quickly moving workloads and applications, but it also makes it difficult to track changes. Many AWS containers share memory and CPU resources with a variety of hosts (physical and cloud) in your ecosystem. Consequently, monitoring resource consumption and assessing container performance and application health can be difficult — after all, how can you know how much memory is being utilized by the container or the physical host?
Traditional monitoring tools and solutions also fail to collect the necessary metrics or provide the crucial insights needed for monitoring and troubleshooting container health and performance. While AWS offers protection for the cloud container structure, visualizing and monitoring what happens within the container is the responsibility of your organization.
As your company grows and you scale your cloud infrastructure, your DevOps teams will continue to create containers. For example, Google runs everything in containers and launches an epic amount of containers (several billion per week!) to keep up with their developer and client needs. While you might not be launching quite as many containers, it’s still easy to lose track of them all. Organizations utilize alerts to keep track of container performance and health to resolve problems quickly. While alerting policies differ, most companies use metric- or log-based alerting.
It can be overwhelming to manage and remediate all of your organization’s container alerts. Not only do these alerts need to be routed to the proper developer or resource owner, but they also need to be remediated quickly to ensure the security and continued good performance of the container.
While AWS provides security for your foundational services in containerized applications — computing, storage, databases, and networking — it’s your responsibility to develop sufficient security protocols to protect your data, applications, operating system, and firewall. In the same way that your organization follows external cybersecurity standards for security and compliance across the rest of your digital ecosystem, it’s best to align your client-side AWS container security with a well-known industry framework.
Adopting a standardized cybersecurity framework will work in concert with AWS’s security measures by providing guidelines and best practices — preventing your organization from a haphazard security application that creates coverage gaps.
Now that you know why your organization needs client-side security, here’s how Rapid7 can help.
AWS’s shared responsibility model of security helps relieve operational burdens for organizations operating cloud containers. AWS clients don’t have to worry about the infrastructure security of their cloud containers. The contents in the cloud containers, however, are the owner’s responsibility and require additional security considerations.
Client-side security is necessary for proper monitoring and visibility, reduction in alert fatigue and real-time troubleshooting, and the application of external cybersecurity frameworks. The right tools, like Rapid7’s InsightCloudSec, can provide crucial support in each of these areas and beyond, filling crucial expertise and staffing gaps on your team and empowering your organization to confidently (and securely) utilize cloud containers.
Want to learn more about AWS container security? Download Fortify Your Containerized Apps With Rapid7 on AWS.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/08/parmesan-anti-forgery-protection.html
The Guardian is reporting about microchips in wheels of Parmesan cheese as an anti-forgery measure.
Post Syndicated from corbet original https://lwn.net/Articles/941867/
The LWN.net Weekly Edition for August 24, 2023 is available.
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=SiUxXX_RR_U
Post Syndicated from Hajer Bouafif original https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-h1-2023-in-review/
Since its release in January 2021, the OpenSearch project has released 14 versions through June 2023. Amazon OpenSearch Service supports the latest versions of OpenSearch up to version 2.7.
OpenSearch Service provides two configuration options to deploy and operate OpenSearch at scale in the cloud. With OpenSearch Service managed domains, you specify a hardware configuration and OpenSearch Service provisions the required hardware and takes care of software patching, failure recovery, backups, and monitoring. With managed domains, you can use advanced capabilities at no extra cost such as cross-cluster search, cross-cluster replication, anomaly detection, semantic search, security analytics, and more. You don’t need a large team to maintain and operate your OpenSearch Service domain at scale. Your team should be familiar with sharding concepts and OpenSearch best practices to use the OpenSearch managed offering.
Amazon OpenSearch Serverless provides a straightforward and fully auto scaled deployment option. When you use OpenSearch Serverless, you create a collection (a set of indexes that work together on one workload) and use OpenSearch’s APIs, and OpenSearch Serverless does the rest. You don’t need to worry about sizing, capacity planning, or tuning your OpenSearch cluster.
In this post, we provide a review of all the exciting features releases in OpenSearch Service in the first half of 2023.
In this section, we discuss some of the features in OpenSearch Service that enable you to build powerful search solutions.
Earlier this year, we announced the general availability of OpenSearch Serverless. OpenSearch Serverless separates storage and compute components, and indexing and query compute, so they can be managed and scaled independently. It uses Amazon Simple Storage Service (Amazon S3) as the primary data storage for indexes, adding durability for your data. Collections are able to take advantage of the S3 storage layer to reduce the need for hot storage, and reduce cost, by bringing data into local store when it’s accessed.
When you create a serverless collection, you set a collection type. OpenSearch Serverless optimizes resource use depending on the type you set. At release, you could create search and time series collections for full-text search and log analytics use cases, respectively. In July 2023, we previewed support for a third collection type: vector search. The vector engine for OpenSearch Serverless is a simple, scalable, and high-performing vector store and query engine that enables generative AI, semantic search, image search, and more. Built on OpenSearch Serverless, the vector engine inherits and benefits from its robust architecture. With the vector engine, you don’t have to worry about sizing, tuning, and scaling the backend infrastructure. The vector engine automatically adjusts resources by adapting to changing workload patterns and demand to provide consistently fast performance and scale. The vector engine uses approximate nearest neighbor (ANN) algorithms from the Non-Metric Space Library (NMSLIB) and FAISS libraries to power k-NN search.
You can start using the new vector engine capabilities by selecting Vector search when creating your collection on the OpenSearch Service console. Refer to Introducing the vector engine for Amazon OpenSearch Serverless, now in preview for more information about the new vector search option with OpenSearch Serverless.
Point in Time (PIT) search, released in version 2.4 of OpenSearch Project and supported in OpenSearch 2.5 in OpenSearch Service, provides consistency in search pagination even when new documents are ingested or deleted within a specific index. For example, let’s say your website user searched for “blue couch” and spent a few minutes looking at the results. During those few minutes, the application added some additional couches to the index, shifting the order of the first 20 documents. If the user then navigates from page 1 to page 2, they may see results that were already on page 1 but have shifted down in the result order. The pagination is not stable over the addition of new data to the index. If you use PIT search, the result order is guaranteed to remain the same across pages, regardless of changes to the index. To learn more about PIT capabilities, refer to Launch highlight: Paginate with Point in Time.
Ever wondered what would happen if you adjusted your relevance function—would the results be better, or worse? With the search relevance plugin, you can now view a side-by-side comparison of results in OpenSearch Dashboards. A UI view makes it simple to see how the results have changed and dial in your relevance to perfection.
OpenSearch 2.7 (available in OpenSearch Service) supports the following new object mapping types:
Starting from OpenSearch 2.7 in OpenSearch Service, you can run GeoHex grid aggregation queries on datasets built with the Hexagonal Hierarchical Geospatial Indexing System (H3) open-source library. H3 provides precision down to the square meter or less, making it useful for cases that require a high degree of precision. Because high-precision requests are compute heavy, you should be sure to limit the geographic area using filters.
Observability in OpenSearch is a collection of plugins and features that let you explore, query and visualize telemetry data stored in OpenSearch. In this section, we discuss how OpenSearch Service enables you to take Observability to the next level.
With version 2.6, the OpenSearch Project released a new unified schema for Observability named Simple Schema for Observability (SS4O) (supported in OpenSearch 2.7 in OpenSearch Service). SS4O is inspired by both OpenTelemetry and the Elastic Common Schema (ECS) and uses Amazon Elastic Container Service (Amazon ECS) event logs and OpenTelemetry (OTel) metadata. SS4O specifies the index structure (mapping), index naming conventions, an integration feature for adding preconfigured dashboards and visualizations, and a JSON schema for enforcing and validating the structure. SS4O complies with the OTEL schema for logs, traces, and metrics.
With the release of OpenSearch 2.5, you can now integrate Jaeger trace data in OpenSearch and use the Observability plugin to analyze your trace data in Jaeger format.
Observability provides you with visibility on the health of your system and microservice applications. OpenSearch Dashboards comes with an Observability plugin, which provides a unified experience for collecting and monitoring metrics, logs, and traces from common data sources. With the Observability plugin, you can monitor and alert on your logs, metrics, and traces to ensure that your application is available, performant, and error-free.
In the first half of 2023, we added the capability to create Observability dashboards and standard dashboards from the OpenSearch Dashboards main menu. Before that, you needed to navigate to the Observability plugin to create event analytics visualizations using Piped Processing Language (PPL). With this release, we made this feature more accessible by integrating a new type of visualization named “PPL” within the list of visualization types on the Dashboards main menu. This helps you correlate both business insights and observability analytics in a single place.
In April of 2023, OpenSearch Service released Amazon OpenSearch Ingestion, a fully managed and auto scaled ingestion pipeline for OpenSearch Service domains and OpenSearch Serverless collections. OpenSearch ingestion is powered by Data Prepper, with source and sink plugins to process, sample, filter, enrich, and deliver data for downstream analysis. Refer to Supported plugins and options for Amazon OpenSearch Ingestion pipelines to learn more.
The service automatically accommodates your workload demands by scaling up and down the OpenSearch Compute units (OCUs). Each OCU provides an estimated 8 GB per hour of throughput (your workload will determine the actual throughput) and is a combination of 8 GiB of memory and 2 vCPUs. You can scale up to 96 OCUs.
OpenSearch ingestion provides out-of-the-box pipeline blueprints that provide configuration templates for the most common ingestion pipelines. For more information, refer to Build a serverless log analytics pipeline using Amazon OpenSearch Ingestion with managed Amazon OpenSearch Service.
In this section, we discuss how you can use OpenSearch Service to enable your business with security features.
SAML authentication for OpenSearch Dashboards was introduced in OpenSearch Service domains with Elasticsearch version 6.7 or higher and OpenSearch version 1.0 or higher, but you had to wait for the domain to be created to enable SAML. In February 2023, we enabled you to specify SAML support during domain creation. Support is available when you create domains on the AWS Management Console, AWS SDK, or AWS CloudFormation templates. SAML authentication for OpenSearch Dashboards enables you to integrate directly with identity providers (IdPs) such as Okta, Ping Identity, OneLogin, Auth0, Active Directory Federation Services (ADFS), and Azure Active Directory.
OpenSearch 2.5 in OpenSearch Service launched support for OpenSearch’s security analytics plugin. In the past, identifying actionable security alerts and gaining valuable insights required significant expertise and familiarity with various security products. However, with security analytics, you can now benefit from simplified workflows that facilitate correlating multiple security logs and investigating security incidents, all within the OpenSearch environment, even without prior security experience. The security analytics plugin is bundled with an extensive collection of over 2,200 open-source Sigma security rules. These rules play a crucial role in detecting potential security threats in real time from your event logs. With the security analytics plugin, you can also design custom rules, tailor security alerts based on threat severity, and receive automated notifications at your preferred destination, such as email or a Slack channel. For more information about creating detectors and configuring rules, refer to Identify and remediate security threats to your business using security analytics with Amazon OpenSearch Service.
In June 2023, OpenSearch Ingestion added support for real-time ingestion of events from Amazon Security Lake, reducing indexing time for security data in OpenSearch Service. With Amazon Security Lake centralizing security data from various sources, you can take advantage of the extensive security analytics capabilities and rich dashboard visualizations of OpenSearch Service to gain valuable insights quickly. Using the Open Cybersecurity Schema Framework (OCSF), Amazon Security Lake normalizes and combines data from diverse enterprise security sources in Apache Parquet format. OpenSearch Ingestion now enables ingestion in Parquet format, with built-in processors to convert data into JSON documents before indexing. Additionally, there’s a specialized blueprint for ingesting data from Amazon Security Lake and support for Data Prepper 2.3.0, offering new features like S3 sink, Avro codec, obfuscation processor, event tagging, advanced expressions, and tail sampling.
In this section, we discuss how you can use OpenSearch Service to simplify cluster operations.
OpenSearch Service has introduced an enhanced dry run option that allows you to validate configuration changes before applying them to your clusters. This feature ensures that any potential validation errors that might occur during the deployment of configuration changes are checked and summarized for your review. Additionally, the dry run will indicate whether a blue/green deployment is necessary to apply a change, enabling you to plan accordingly.
OpenSearch Service now offers 99.99% availability with Multi-AZ with Standby deployment. This new capability makes your business-critical workloads more resilient to potential infrastructure failures such as Availability Zone failure. Prior to this new launch, OpenSearch Service automatically recovered from Availability Zone outages by allocating more capacity in the impacted Availability Zone and automatically redistributing shards. However, this approach is a reactive approach to infrastructure and network failures, and usually led to high latency and increased resource utilization across the nodes. The Multi-AZ with Standby feature deploys infrastructure in three Availability Zones, while keeping two zones as active and one zone as standby. It requires a minimum of two replicas to maintain data redundancy across Availability Zones for a recovery time in less than a minute.
With the release of the Skip unavailable clusters option for cross-cluster search in June 2023, your cross-cluster search queries will return results even if you have unavailable shards or indexes on one of the remote clusters. The feature is enabled by default when you request connection to a remote cluster on the OpenSearch Service console.
The release of OpenSearch 2.5 and OpenSearch 2.7 in OpenSearch Service has brought new features to manage data streams and indexes on the OpenSearch Dashboards UI.
By default, OpenSearch Service takes hourly snapshots of your data with a retention time of 14 days. The automatic snapshots are incremental in nature and help you recover from data loss or cluster failure. In addition to the default hourly snapshots, OpenSearch Service provides the capability to run manual snapshots and store them in an S3 bucket. You can use snapshot management to create manual snapshots, define a snapshot retention policy, and set up the frequency and timing of snapshot creation. Snapshot management is available under the index management plugin in OpenSearch Dashboards.
With the support of OpenSearch 2.5 and OpenSearch 2.7 in OpenSearch Service , you can now use the index management plugin in OpenSearch dashboards to manage data streams, index templates, and index aliases.
The index management UI provides expended capabilities to include running manual rollover and force merge actions for data streams. You can also visually manage multiple index templates and define index mappings, number of primary shards, number of replicas, and refresh internal for your indexes.
It’s been a busy first half of the year! OpenSearch Project and OpenSearch Service have launched OpenSearch Serverless to use OpenSearch without worrying about infrastructure, index, or shards; OpenSearch Ingestion to ingest your data; the vector engine for OpenSearch Serverless; security analytics to analyze data from Amazon Security Lake; operational improvements to bring 99.99% availability; and improvements to the Observability plugin. OpenSearch Service provides a full suite of capabilities, including a vector database, semantic search, and log analytics engine. We invite you to check out the features described in this post and we appreciate providing us your valuable feedback.
You can get started by having hands-on experience with the publicly available workshops for semantic search, microservice observability, and OpenSearch Serverless. You can also learn more about the service features and use cases by checking out more OpenSearch Service blog posts.
Hajer Bouafif is an Analytics Specialist Solutions Architect at Amazon Web Services. She focuses on Amazon OpenSearch Service and helps customers design and build well-architected analytics workloads in diverse industries. Hajer enjoys spending time outdoors and discovering new cultures.
Aish Gunasekar is a Specialist Solutions Architect with a focus on Amazon OpenSearch Service. Her passion at AWS is to help customers design highly scalable architectures and help them in their cloud adoption journey. Outside of work, she enjoys hiking and baking.
Jon Handler is a Senior Principal Solutions Architect at Amazon Web Services based in Palo Alto, CA. Jon works closely with OpenSearch and Amazon OpenSearch Service, providing help and guidance to a broad range of customers who have search and log analytics workloads that they want to move to the AWS Cloud. Prior to joining AWS, Jon’s career as a software developer included 4 years of coding a large-scale, ecommerce search engine. Jon holds a Bachelor of the Arts from the University of Pennsylvania, and a Master of Science and a PhD in Computer Science and Artificial Intelligence from Northwestern University.
Post Syndicated from Gleb Budman original https://www.backblaze.com/blog/2023-product-announcement/
Over the coming months, Backblaze will make big updates and upgrades to both our products—B2 Cloud Storage and Computer Backup. Considering the volume of new stuff on the horizon, I’m dropping into the blog today to explain what’s happening, when, and why for our customers as well as any others who are considering adopting our services. Here’s what’s new.
Meeting and exceeding customers’ needs for building applications, protecting data, supporting media workflows, and more is the top priority for B2 Cloud Storage. To further these efforts, we’ll be implementing the following updates:
Storage Price: Effective October 3, 2023, we are increasing the monthly pay-as-you-go storage rate from $5/TB to $6/TB. The price of B2 Reserve will not change.
Free Egress: Also effective October 3, we’re making egress free (i.e. free download of data) for all B2 Cloud Storage customers—both pay-as-you-go and B2 Reserve—up to three times the amount of data you store with us, with any additional egress priced at just $0.01/GB. Because supporting an open cloud environment is central to our mission, expanding free egress to all customers so they can move data when and where they prefer is a key next step.
From Object Lock for ransomware protection, to Cloud Replication for redundancy, to more data centers to support data location needs, Backblaze has consistently improved B2 Cloud Storage. Stay tuned for more this fall, when we’ll announce upload performance upgrades, expanded integrations, and more partnerships.
Storage pricing on committed contracts, B2 Reserve pricing, and unlimited free egress between Backblaze B2 and many leading content delivery network (CDN) and compute partners are all not changing.
1. Continuing to provide the best cloud storage.
I am excited that B2 Cloud Storage continues to be the best high-quality and low-cost alternative to traditional cloud providers like AWS for businesses of all sizes. After seven years in service with no price increases, the bar was very high for considering any change to our pricing. We invest in making Backblaze B2 a better cloud storage provider every day. A price increase enables us to continue doing so into the future.
2. Advancing the freedom of customers’ data.
We’ve heard from customers that one of the greatest benefits of B2 Cloud Storage is freedom—freedom from complexity, runaway bills, and data lock-in. We wanted to double down on these benefits and further empower our customers to leverage the open cloud to use their data how and where they wish. Making egress free supports all these benefits for our customers.
To expand our ability to provide astonishingly easy computer backup that is as reliable as it is trustworthy and affordable, we’re instituting the following updates to Backblaze Computer Backup and sharing some upcoming product upgrades:
Since launching Computer Backup in 2008, we’ve stayed committed to a product that backs up all your data automatically to the cloud for a flat rate. Over the following 15 years, the average amount of data stored per user has grown tremendously, and our investments to build out our storage cloud to support that growth has increased to keep pace.
At the same time, we’ve continued to invest in improving the product—as we have been recently with the upcoming release of Version 9.0, in our active development of new Group administration features, and in the free addition of optional One Year Extended Version history for all users. And, we still have more to do to ensure our product consistently lives up to its promise.
To continue offering unlimited backup, innovating, and adding value to the best computer backup service, we need to align our pricing with our costs.
We understand how valuable your data is to your business and your life, and the trust you place in Backlaze every day is not lost on me. We are deeply committed to our mission of making storing, using, and protecting that data astonishingly easy, and the updates I’ve shared today are a big step forward in ensuring we can do so for the long haul. So, in closing, I’ll say thank you for entrusting us with your precious data—we’re honored to serve you.
Maybe. This update applies to B2 Cloud Storage pay-as-you-go customers—those who pay variable monthly amounts based on their actual consumption of the service—who have not entered into committed contracts for one or more years.
The updated pricing is effective October 3, 2023, so you will see it applied starting from this date to bills sent after this date.
Backblaze measures pay-as-you-go customers’ usage in byte hours. The monthly storage average is based on the byte hours. As of October 3, 2023, monthly egress up to three times your average is free; any monthly egress above this 3x average is priced at $0.01 per GB.
Yes. This change has no impact on the unlimited free egress that Backblaze offers through leading CDN and compute partners including Fastly, Cloudflare, CacheFly, bunny.net, and Vultr.
B2 Reserve bundles start at 20TB. You can explore B2 Reserve with our Sales Team here to discuss making a switch.
Yes. Backblaze remains highly affordable compared to other cloud storage providers. The service also remains roughly one-fifth the cost of AWS S3 for the combination of hot storage and egress, with the exact difference varying based on usage. For example, if you store 10TB in the U.S. West and also egress 10% of it in a month, your pricing from Backblaze and AWS is as follows:
Backblaze B2: Storage $6/TB + Egress $0/GB = $60
AWS S3: Storage $26/TB + Egress $0.09/GB = Storage $260 + Egress $90 = $350
In this instance, Backblaze is 17% or about one-fifth the cost of AWS S3.
Beyond including free egress for all customers, we have a number of other upgrades and improvements in the pipeline. We’ll be announcing them in the coming months, but they include improvements to the upload experience, features to expand use cases for application storage customers, new integrations, and more partnerships.
No. This is the extent of the update effective October 3, 2023. We also continue to believe that minimum storage duration fees as levied by some vendors run counter to the interests of many customers.
This is the only price increase we have had since we launched B2 Cloud Storage in 2015.
Monthly licenses will be $9, yearly licenses will be $99, and two-year licenses will be $189. One Year Extended Version History will be available for free to those who wish to enable it. The $2 per month charge for Forever Version History will be removed while the incremental rate for when a file has been changed, modified, or deleted over a year ago will be $0.006/GB/month.
October 3, 2023 at 00:00 UTC is when the price increase will go into effect for new purchases and renewals. Existing contracts and licenses will be honored for their duration, and any prorated purchases after that time will be prorated at the new rate.
Extended Version History allows you to “go back in time” further to retrieve earlier versions of your data. By default that setting is set to 30 days. With this update, you can choose to keep versions up to one year old for free.
When an individual file is changed, updated, edited, or deleted, without the file name changing, a new version is created.
On October 3, 2023, we’ll be removing the charge for selecting One Year Extended Version History. Any changes made to that setting ahead of that date will result in a prorated charge to the payment method on file.
Yes. We will not be changing anyone’s settings on their behalf, so please see below for instructions on how to change your version history settings to one year. Note: making changes to this setting before October 3 will result in a prorated charge, as noted above.
For individual Backblaze users: simply log in to your Backblaze account and navigate to the Overview page. From there you’ll see a list of all your computers and their selected Version History. To make a change, press the Update button next to the computer you wish to add One Year Extended Version History for.
For Group admins: simply log in to your Backblaze account and navigate to the Groups Management page. From there, you’ll see a list of all of the Groups you manage and their selected Version History. To make a change, press the Update button next to the Group you wish to enable One Year Extended Version History for, and all computers within it will be enabled.
Yes. Forever Version History is still available. The prior $2 per month charge will be removed, and only files changed, deleted, or modified over a year ago will be charged at the incremental $0.006/GB/month.
It depends on your payment plan. If you are on a monthly plan with One Year Extended Version History, you will not see an increase. However, anyone on a yearly plan will see an increase from $94 to $99, and for two-year licenses, your price will increase from $178 to $189.
The post Backblaze Product and Pricing Updates appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.
Post Syndicated from jake original https://lwn.net/Articles/942529/
Greg Kroah-Hartman has announced the release of two new stable kernels: 6.4.12 and 6.1.47. Both contain lots of important fixes
throughout the kernel tree.
Post Syndicated from Emilie Ma original http://blog.cloudflare.com/introducing-the-2023-intern-ets/
This year, Cloudflare welcomed a class of approximately 40 interns, hailing from five different countries for an unforgettable summer. As we joined both remotely and in-person across Cloudflare’s global offices, our experiences spanned a variety of roles from engineering, product management to internal auditing and marketing. Through invaluable mentorship, continuous learning, and the chance to make a real-world impact, our summer was truly enriched at every step. Join us, Anni and Emilie, as we provide an insider's perspective on a summer at Cloudflare, sharing snippets and quotes from our intern cohort.
You might have noticed that we have a new name for the interns: the Intern-ets! Our fresh intern nickname was born from a brainstorm between us and our recruiter, Judy. While “Cloudies”, “Cloudterns”, and “Flaries” made the shortlist, a company-wide vote crowned "Intern-ets" as the favorite. And just like that, we've made Cloudflare history!
We're all incredibly proud to have gotten the opportunity to tackle interesting and highly impactful projects throughout the duration of our internships. To give you a glimpse of our summer, here are a few that showcase the breadth and depth of our experiences.
Mia M., Product Manager intern, worked on the Cloudflare Secrets Store, which is a new product that will allow Cloudflare customers to store, encrypt, and deploy sensitive data across the product suite. She focused on creating requirements for the core platform and tackling the first milestone, bringing secrets and environment variables from the per-Worker level to the account level in the Workers platform.
Pierre, Research intern, focused on integrating differential privacy—a layer of protection with formal privacy guarantees—into distributed aggregation protocols. This privacy layer is imperative for user trust and data security as these protocols are commonly used for collecting sensitive information, such as browser telemetry or health data.
Johnny, Software Engineer intern, worked on a new feature for API Shield called Object-Level Access Policies as a first step in a solution to combat Broken Object-Level Authorization, which has been ranked as the #1 API Security flaw by OWASP. This feature will enable customers to specify explicit allowlists and blocklists for API traffic per object.
Olivia, Project Manager intern, led the Dissatisfied (DSAT) Customer Outreach Project and JIRA Automations for the Customer Support team. The DSAT project involves reaching out to Premium customers who express dissatisfaction with the goal of providing personalized contact to ensure they feel valued. The JIRA Automation project aims to create zero-touch tickets, removing Customer Support as the middle man.
Also don’t forget to check out the amazing intern projects that got featured in a blog post!
Emilie, Software Engineering intern introduced a debugging feature for Cloudflare Queues.
Joaquin, Software Engineer intern added a new Workers Database integration.
Austin, Software Engineer intern created scheduled deletion for Cloudflare Stream.
Beyond our projects, we had tons of fun getting to meet other Cloudflarians and experience the vibrant Cloudflare culture. Let's dive into some of the standout moments that made our internships truly special!
This summer, the interns dotted the globe, working from cozy home setups to bustling offices in cities. Regardless of where we worked, we had a blast. Here's what some fellow interns have to say about their work experiences:
Austin office: Jada loved her colleagues at the Austin office as they were “warm and open to exploring the city, […], and hanging out outside of work”. Anni and Maximo loved attending the Austin-based team summit where they attended strategy sessions and met the team in-person.
San Francisco office: Emmanuel F. enjoyed getting to interact with other engineers during SF Team Lunches. Matthew enjoyed working on the rooftop to a view of the city skyline. Jonathan appreciated the hybrid work model enjoyed by SF employees.
Remote work: Johnny liked the distributed and flexible work style that the company embraces. Daniël, also working remotely and found it amusing how “[s]everal people have noticed the Feynman Lectures on Physics on the shelf behind me in my home and have asked about it.”
Remote intern events: Emmanuel G., Aaron, and Feiyu enjoyed the intern calls that were held on GatherRound as “it was a fun, quick way to get to meet everyone.” Pradyumna particularly liked it when we played skribbl.io.
 |
 |
|---|---|
 |
 |
With so many exceptional minds at Cloudflare, every interaction became a chance for us to learn and grow. Here are some awe-inspiring individuals who have made our internships unforgettable:
Harshal, Systems Engineer: Aaron is grateful for his mentor Harshall. “I always left our conversations knowing more than I did coming into them”.
Revathy, Systems Engineer: Harshini is thankful to her mentor Revathy for “how she helps me to learn […] the best way possible to do something and ultimately achieve my goals”.
Nevi, Product Manager: Anni admires her manager Nevi who is always thinking about the team and our customers and has invested in the personal growth and mentorship of interns.
Conner, Systems Engineer: Jonathan is grateful that he was always able to count on Conner for great engineering tips, guidance, and NeoVim wizardry.
Malgorzata, Data Scientist: Jada looks up to Malgorzata for being so welcoming, kind, and funny. She has a great attitude and besides being super knowledgeable, she is also willing to share her expertise and support others!
During our internships, we engaged in Executive fireside chats, diving deep with Cloudflare's top leaders. Each chat was insightful and surprising in a different way, and some of our favorite takeaways were…
John, CTO: Shaheen valued John’s humility in emphasizing daily learning from others at work, stating, “As I grow in my career, I intend to keep a similar attitude and try to learn from those around me by keeping myself grounded.”
Doug Kramer, General Counsel: Emilie valued Doug Kramer's advice on identifying a career "north star" to guide intentions while also recognizing "exit-ramps" or alternative paths that may offer unexpected fulfillment.
Matthew Prince, Co-founder and CEO: Yunfan loved hearing “the story about how Cloudflare developed from a start-up till today”.
Michelle Zatlyn, Co-founder and COO: Harsh learned from Michelle about “how they moved across the country, against everyone's advice, to start Cloudflare”, and Mia C. enjoyed learning that “Cloudflare started as a business school project”.
A bonding point for the Intern-ets was our love for snacks! In July, we gathered the Intern-ets together for a virtual snack break. The University team sent out a box featuring snacks from Indonesia, a country none of us had visited (or tried goodies from… yet!). Below you can see us holding up our favorite snacks from the box!
Meanwhile, the on-site interns couldn't get enough of the office snacks. Favorites? Pita chips, Lucky Charms, chocolate almonds, coconut chocolate bars and coconut water. Plus, the Austin and San Francisco offices even have a Sour Patch Kids dispenser! Snack on!
Every day at Cloudflare presented unexpected joys and challenges. Here's what the interns found most surprising:
High Impact: Simon, Emmanuel F. and Maximo were surprised to “[do] such visible and important work as an intern”. Austin agreed, noting “I was treated like any other member of the team […] It felt like I was working on something important and not just a typical intern project!” Harshini added, “when [colleagues] hear what I am working on they go – ‘that is really cool, I can't wait to see that happen – we need it.’”
Support: Eames “was worried that it would feel like my achievements were the only thing that mattered. But my colleagues always showed concern for how I was feeling and how things were going, and I couldn't be more grateful for that.”
Industry vs Academia: Johnny mentioned “coming from academia, I was amazed by the amount of effort that has been, and is continuing to be, put into the products to really productionize what I have only before seen in research. It is another reminder of the scale in which we work!”
Here are some fun stats from our internship…
At Cloudflare, our internships aren’t just about work—they're about growth, mentorship, and real impact. We've built more than projects; we've forged lasting relationships. It’s been an unforgettable summer of challenges, bonding, and authentic experiences. For more about our journey this summer, check out our Cloudflare TV segment with Michelle Zatlyn, Co-founder and COO.
Finally, we would love to give a huge thanks to our university recruiters Judy, Trang, and Dani for creating such an amazing internship experience for us this summer!
Sign up here to be notified of new grad and internship opportunities for 2024. Cloudflare is also hiring for full-time opportunities: check out open positions and apply today!
Post Syndicated from Rohit Kumar original https://www.servethehome.com/marvell-colorz-800g-silicon-photonics-module-and-orion-dsp-for-next-gen-networks/
Marvell has a new 800G Orion DSP and a COLORZ 800 module line using Orion and silicon photonics for 800Gbps networking
The post Marvell COLORZ 800G Silicon Photonics Module and Orion DSP for Next-Gen Networks appeared first on ServeTheHome.
Post Syndicated from Matt Garman original https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-announcing-new-dedicated-infrastructure-options/
At AWS, we’re committed to helping our customers meet digital sovereignty requirements. Last year, I announced the AWS Digital Sovereignty Pledge, our commitment to offering all AWS customers the most advanced set of sovereignty controls and features available in the cloud. Our approach is to continue to make AWS sovereign-by-design—as it has been from day one.
I promised that our pledge was just the start, and that we would continue to innovate to meet the needs of our customers. As part of our promise, we pledged to invest in an ambitious roadmap of capabilities on data residency, granular access restriction, encryption, and resilience. Today, I’d like to update you on another milestone on our journey to continue to help our customers address their sovereignty needs.
Customers have always controlled the location of their data with AWS. For example, in Europe, customers have the choice to deploy their data into any of eight existing AWS Regions. These AWS Regions provide the broadest set of cloud services and features, enabling our customers to run the majority of their workloads. Customers can also use AWS Local Zones, a type of infrastructure deployment that makes AWS services available in more places, to help meet latency and data residency requirements, without having to deploy self-managed infrastructure. Customers who must comply with data residency regulations can choose to run their workloads in specific geographic locations where AWS Regions and Local Zones are available.
Our public sector and regulated industry customers have told us they want dedicated infrastructure for their most critical workloads to help meet regulatory or other compliance requirements. Many of these customers manage their own infrastructure on premises for workloads that require isolation. This forgoes the performance, innovation, elasticity, scalability, and resiliency benefits of the cloud.
To help our customers address these needs, I’m excited to announce AWS Dedicated Local Zones. Dedicated Local Zones are a type of AWS infrastructure that is fully managed by AWS, built for exclusive use by a customer or community, and placed in a customer-specified location or data center to help comply with regulatory requirements. Dedicated Local Zones can be operated by local AWS personnel and offer the same benefits of Local Zones, such as elasticity, scalability, and pay-as-you-go pricing, with added security and governance features. These features include data access monitoring and audit programs, controls to limit infrastructure access to customer-selected AWS accounts, and options to enforce security clearance or other criteria on local AWS operating personnel. With Dedicated Local Zones, we work with customers to configure their own Local Zones with the services and capabilities they need to meet their regulatory requirements.
AWS Dedicated Local Zones meet the same high AWS security standards that apply to AWS Regions and Local Zones. They also come with the same AWS Nitro System that powers all modern Amazon Elastic Compute Cloud (Amazon EC2) instances to help ensure confidentiality and integrity of customer data. With Dedicated Local Zones, customers can use the multitenancy features of the cloud to efficiently enable adoption across multiple AWS accounts created by a customer’s community of agencies and business units, and reduce the operational overhead of managing on-premises infrastructure. Customers can deploy multiple Dedicated Local Zones for resiliency and simplify their applications’ architecture by using consistent AWS infrastructure, APIs, and tools across different classifications of applications running in AWS Regions and Dedicated Local Zones. AWS services, such as Amazon EC2, Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS), Elastic Load Balancing (ELB), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Direct Connect, will be available in Dedicated Local Zones.
At AWS, we work closely with customers to understand their requirements for their most critical workloads. Our work with the Singapore Government’s Smart Nation and Digital Government Group (SNDGG) to build a Smart Nation for their citizens and businesses illustrates this approach. This group spearheads Singapore’s digital government transformation and development of the public sector’s engineering capabilities. SNDGG is the first customer to deploy Dedicated Local Zones.
“AWS is a strategic partner and has been since the beginning of our cloud journey. SNDGG collaborated with AWS to define and build Dedicated Local Zones to help us meet our stringent data isolation and security requirements, enabling Singapore to run more sensitive workloads in the cloud securely,” said Chan Cheow Hoe, Government Chief Digital Technology Officer of Singapore. “In addition to helping the Singapore government meet its cybersecurity requirements, the Dedicated Local Zones enable us to offer its agencies a seamless and consistent cloud experience.”
We remain committed to helping our customers meet evolving sovereignty requirements. We continue to innovate sovereignty features, controls, and assurances globally with AWS, without compromising on the full power of AWS.
To get started, you can visit the Dedicated Local Zones website, where you can contact AWS specialists to learn more about how Dedicated Local Zones can be configured to meet your regulatory needs.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
Post Syndicated from jake original https://lwn.net/Articles/942346/
Over the years, there have been multiple examples of open-source software
that, suddenly, was no longer open source; on August 10, some further
examples were added to the pile. That happened when HashiCorp announced
that it would be switching the license on its products from the Mozilla Public
License 2.0 (MPL) to the Business Source License 1.1
(BSL or BUSL). At least one of the products affected by the change, the Terraform infrastructure-automation
tool, has attracted an effort to continue it as an open-source tool in the
form of a fork that would be maintained by the nascent OpenTF Foundation. That seems like a
sensible reaction to the move, but it also helps serve up yet another
reminder that code which is controlled by a single entity is normally
always at risk of such
adverse changes.
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=ZI2bQ6bWfOM
Post Syndicated from jake original https://lwn.net/Articles/942514/
Security updates have been issued by Debian (mediawiki and qt4-x11), Fedora (java-17-openjdk, linux-firmware, and python-yfinance), Red Hat (kernel, kpatch-patch, and subscription-manager), SUSE (evolution, janino, kernel, nodejs16, nodejs18, postgresql15, qt6-base, and ucode-intel), and Ubuntu (inetutils).
Post Syndicated from James Beswick original https://aws.amazon.com/blogs/compute/protecting-an-aws-lambda-function-url-with-amazon-cloudfront-and-lambdaedge/
This post is written by Jerome Van Der Linden, Senior Solutions Architect Builder.
A Lambda function URL is a dedicated HTTPs endpoint for an AWS Lambda function. When configured, you can invoke the function directly with an HTTP request. You can choose to make it public by setting the authentication type to NONE for an open API. Or you can protect it with AWS IAM, setting the authentication type to AWS_IAM. In that case, only authenticated users and roles are able to invoke the function via the function URL.
Lambda@Edge is a feature of Amazon CloudFront that can run code closer to the end user of an application. It is generally used to manipulate incoming HTTP requests or outgoing HTTP responses between the user client and the application’s origin. In particular, it can add extra headers to the request (‘Authorization’, for example).
This blog post shows how to use CloudFront and Lambda@Edge to protect a Lambda function URL configured with the AWS_IAM authentication type by adding the appropriate headers to the request before it reaches the origin.
There are four main components in this example:
This is the example architecture:
The request flow is:
lambda:InvokeFunctionUrl permission on the target Lambda function URL and uses this to sign the request with the signature V4. It adds the Authorization, X-Amz-Security-Token, and X-Amz-Date headers to the request.There are several types of events where a Lambda@Edge function can be triggered:
The current example, to update the request before it is sent to the origin (the Lambda function URL), uses the “Origin Request” type.
You can find the complete example, based on the AWS Cloud Development Kit (CDK), on GitHub.
The backend contains the different Lambda functions and Lambda function URLs. It uses the AWS_IAM auth type and the CORS (Cross Origin Resource Sharing) definition when adding the function URL to the Lambda function. Use a more restrictive allowedOrigins for a real application.
const getBookFunction = new NodejsFunction(this, 'GetBookFunction', {
runtime: Runtime.NODEJS_18_X,
memorySize: 256,
timeout: Duration.seconds(30),
entry: path.join(__dirname, '../functions/books/books.ts'),
environment: {
TABLE_NAME: bookTable.tableName
},
handler: 'getBookHandler',
description: 'Retrieve one book by id',
});
bookTable.grantReadData(getBookFunction);
const getBookUrl = getBookFunction.addFunctionUrl({
authType: FunctionUrlAuthType.AWS_IAM,
cors: {
allowedOrigins: ['*'],
allowedMethods: [HttpMethod.GET],
allowedHeaders: ['*'],
allowCredentials: true,
}
});
The Frontend stack contains the CloudFront distribution and the Lambda@Edge function. This is the Lambda@Edge definition:
const authFunction = new cloudfront.experimental.EdgeFunction(this, 'AuthFunctionAtEdge', {
handler: 'auth.handler',
runtime: Runtime.NODEJS_16_X,
code: Code.fromAsset(path.join(__dirname, '../functions/auth')),
});
The following policy allows the Lambda@Edge function to sign the request with the appropriate permission and to invoke the function URLs:
authFunction.addToRolePolicy(new PolicyStatement({
sid: 'AllowInvokeFunctionUrl',
effect: Effect.ALLOW,
actions: ['lambda:InvokeFunctionUrl'],
resources: [getBookArn, getBooksArn, createBookArn, updateBookArn, deleteBookArn],
conditions: {
"StringEquals": {"lambda:FunctionUrlAuthType": "AWS_IAM"}
}
}));
The function code uses the AWS JavaScript SDK and more precisely the V4 Signature part of it. There are two important things here:
InvokeFunctionUrl permission)const request = new AWS.HttpRequest(new AWS.Endpoint(`https://${host}${path}`), region);
// ... set the headers, body and method ...
const signer = new AWS.Signers.V4(request, 'lambda', true);
signer.addAuthorization(AWS.config.credentials, AWS.util.date.getDate());
You can get the full code of the function here.
The CloudFront distribution has a default behavior with an S3 origin for the static assets of the React application.
It also has one behavior per function URL, as defined in the following code. You can notice the configuration of the Lambda@Edge function with the type ORIGIN_REQUEST and the behavior referencing the function URL:
const getBehaviorOptions: AddBehaviorOptions = {
viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY,
cachePolicy: CachePolicy.CACHING_DISABLED,
originRequestPolicy: OriginRequestPolicy.CORS_CUSTOM_ORIGIN,
responseHeadersPolicy: ResponseHeadersPolicy.CORS_ALLOW_ALL_ORIGINS_WITH_PREFLIGHT,
edgeLambdas: [{
functionVersion: authFunction.currentVersion,
eventType: LambdaEdgeEventType.ORIGIN_REQUEST,
includeBody: false, // GET, no body
}],
allowedMethods: AllowedMethods.ALLOW_GET_HEAD_OPTIONS,
}
this.distribution.addBehavior('/getBook/*', new HttpOrigin(Fn.select(2, Fn.split('/', getBookUrl)),), getBehaviorOptions);
The Lambda@Edge function must be in the us-east-1 Region (N. Virginia), as does the frontend stack. If you deploy the backend stack in another Region, you’ll must pass the Lambda function URLs (and ARNs) to the frontend. Using a custom resource in CDK, it’s possible to create parameters in AWS Systems Manager Parameter Store in the us-east-1 Region containing this information. For more details, review the code in the GitHub repo.
Before deploying the solution, follow the README in the GitHub repo and make sure to meet the prerequisites.
npm installcdk deploy --all
GetBooksFunctionURL in the CDK outputs):
curl -v https://qwertyuiop1234567890.lambda-url.eu-west-1.on.aws/
You should get the following output. As expected, it’s forbidden to directly access the Lambda function URL without the proper IAM authentication:
GetBooksURL in the CDK outputs):
curl -v https://q1w2e3r4t5y6u.cloudfront.net/getBooks
This time you should get a HTTP 200 OK with an empty list as a result.
The logs of the Lambda@Edge function (search for “AuthFunctionAtEdge” in CloudWatch Logs in the closest Region) show:
Authorization, X-Amz-Security-Token, and X-Amz-Date). These headers make the difference when the Lambda URL receives the request and validates it with IAM.
You can test the complete solution throughout the frontend, using the FrontendURL in the CDK outputs.
The Lambda@Edge function is replicated in all Regions where you have users. You must delete the replicas before deleting the rest of the solution.
To delete the deployed resources, run the cdk destroy --all command from the solution directory.
This blog post shows how to protect a Lambda Function URL, configured with IAM authentication, using a CloudFront distribution and Lambda@Edge. CloudFront helps protect from DDoS, and the function at the edge adds appropriate headers to the request to authenticate it for Lambda.
Lambda function URLs provide a simpler way to invoke your function using HTTP calls. However, if you need more advanced features like user authentication with Amazon Cognito, request validation or rate throttling, consider using Amazon API Gateway.
For more serverless learning resources, visit Serverless Land.
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=PxlaaHix2q0
Post Syndicated from Rapid7 original https://blog.rapid7.com/2023/08/23/3-security-vendor-consolidation-myths/
When it comes to security vendor consolidation, Gartner found that 57% of organizations are working with fewer than ten security vendors, utilizing consolidation to cut costs and improve their overall security posture.
But what about the other 43%?
While security vendor consolidation has many advantages — like improved security and operational efficiency as well as cost reduction and improved ROI — however, it’s clear that some myths about consolidation persist. Let’s take a deeper look at three of the most common consolidation myths:
One of the biggest myths of security vendor consolidation is that after consolidating, organizations will lose access to the superior “best of breed” security approach. “Best of breed” refers to purchasing the best product of each type for your infrastructure’s security needs. This could look like using one vendor for firewall protection, another for observability, a third for remediation, and so on.
While it is true that a “best of breed” approach seems to allow organizations to piece together a tech stack of all the best possible products, that’s not the whole story. Organizations with “best of breed” solutions often end up with technology bloat, or a larger tech stack that requires far more maintenance than single-platform or more streamlined offerings. Additionally, there’s more data created from using tools from multiple vendors, which can actually increase an organization’s attack surface and overall risk level.
Some “best of breed” environments are plagued by interoperability issues — the tools fail to communicate with each other and exchange information properly. This can result in a poorer overall security performance characterized by false alarms and a higher mean time to resolve (MTTR).
Many security teams believe that consolidation locks you into working with a single or smaller number of vendors who may prove to be unreliable or offer subpar services. In reality, you can easily address concerns of vendor performance and flexibility by carefully researching potential vendors before selecting a solution. During the vetting process, ask potential vendors questions around on- and offboarding, security, maintenance, subscription, and licensing fees.
It’s also important to remember that many vendors offer flexibility within their consolidation packages, which means that you often will be able to build a portfolio of products to meet your needs as opposed to being locked into a specific package.
Finally, working with fewer vendors allows you to develop stronger relationships with fewer vendor representatives, resulting in more comprehensive customer service and support.
Many organizations fear that after consolidating, if one of its vendors is compromised, then it presents a serious security risk. This is easily avoidable, however, if organizations practice consolidation across functions and not layers.
In general, secure organizations have layers of security, or redundancies in place to catch and remediate vulnerabilities quickly. This approach, also known as “defense in depth,” may look like a security solution to monitor your endpoints and a separate tool to manage threats in your ecosystem.
You don’t want to consolidate within these layers. For example, let’s imagine that you have the same security provider for both your endpoint monitoring and threat management. If the vendor is compromised and unable to provide protection, your infrastructure would be without endpoint management and threat management at the same time, which presents a serious security risk.
Consequently, you’ll want to consolidate across functions. It may be helpful to picture your security needs within a layer. For example, if you’re looking for greater endpoint protection — monitoring, visibility, and remediation — you can look for consolidation solutions in this area. Consolidating across functions can actually strengthen your security posture. Working from a single platform can improve data sharing across tools, efficiency, and remediation processes, creating a stronger layer of security. Then, if a vendor is compromised, you’ll still have active protection from vendors in your other layers.
Hesitation around security vendor consolidation is understandable. It’s important not to rush and choose the wrong vendor or platform, which can ultimately put your organization at risk. However, widespread consolidation myths may be holding you back from reaping the financial, operational, and security benefits of consolidation.
Lowering costs is a big one. Organizations with a variety of security vendors are paying for each service, and often, multiple licenses. Consolidation offers a chance to cut costs of multiple subscription and licensing fees, as well as reap the benefits of competitively priced consolidation packages.
Consolidation also boosts operational efficiency. Organizations with too many security vendors struggle with visibility, false alarms, and gaps in their infrastructure’s coverage. The interoperability that consolidation offers can eliminate false alarms and boost visibility, while working with security vendors to build a customized consolidated security package that fits your organization’s needs.
When it comes to consolidation, breaking down the major misconceptions can lead to a stronger, more cohesive security solution equipped to handle the rapidly changing threat landscape.
Want to learn more about consolidation and where to get started? Check out our eBook, “The Case for Security Vendor Consolidation.”
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=PbZLP4eJB_Y
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/08/decembers-reimagining-democracy-workshop.html
Imagine that we’ve all—all of us, all of society—landed on some alien planet, and we have to form a government: clean slate. We don’t have any legacy systems from the US or any other country. We don’t have any special or unique interests to perturb our thinking.
How would we govern ourselves?
It’s unlikely that we would use the systems we have today. The modern representative democracy was the best form of government that mid-eighteenth-century technology could conceive of. The twenty-first century is a different place scientifically, technically and socially.
For example, the mid-eighteenth-century democracies were designed under the assumption that both travel and communications were hard. Does it still make sense for all of us living in the same place to organize every few years and choose one of us to go to a big room far away and create laws in our name?
Representative districts are organized around geography, because that’s the only way that made sense 200-plus years ago. But we don’t have to do it that way. We can organize representation by age: one representative for the thirty-one-year-olds, another for the thirty-two-year-olds, and so on. We can organize representation randomly: by birthday, perhaps. We can organize any way we want.
US citizens currently elect people for terms ranging from two to six years. Is ten years better? Is ten days better? Again, we have more technology and therefor more options.
Indeed, as a technologist who studies complex systems and their security, I believe the very idea of representative government is a hack to get around the technological limitations of the past. Voting at scale is easier now than it was 200 year ago. Certainly we don’t want to all have to vote on every amendment to every bill, but what’s the optimal balance between votes made in our name and ballot measures that we all vote on?
In December 2022, I organized a workshop to discuss these and other questions. I brought together fifty people from around the world: political scientists, economists, law professors, AI experts, activists, government officials, historians, science fiction writers and more. We spent two days talking about these ideas. Several themes emerged from the event.
Misinformation and propaganda were themes, of course—and the inability to engage in rational policy discussions when people can’t agree on the facts.
Another theme was the harms of creating a political system whose primary goals are economic. Given the ability to start over, would anyone create a system of government that optimizes the near-term financial interest of the wealthiest few? Or whose laws benefit corporations at the expense of people?
Another theme was capitalism, and how it is or isn’t intertwined with democracy. And while the modern market economy made a lot of sense in the industrial age, it’s starting to fray in the information age. What comes after capitalism, and how does it affect how we govern ourselves?
Many participants examined the effects of technology, especially artificial intelligence. We looked at whether—and when—we might be comfortable ceding power to an AI. Sometimes it’s easy. I’m happy for an AI to figure out the optimal timing of traffic lights to ensure the smoothest flow of cars through the city. When will we be able to say the same thing about setting interest rates? Or designing tax policies?
How would we feel about an AI device in our pocket that voted in our name, thousands of times per day, based on preferences that it inferred from our actions? If an AI system could determine optimal policy solutions that balanced every voter’s preferences, would it still make sense to have representatives? Maybe we should vote directly for ideas and goals instead, and leave the details to the computers. On the other hand, technological solutionism regularly fails.
Scale was another theme. The size of modern governments reflects the technology at the time of their founding. European countries and the early American states are a particular size because that’s what was governable in the 18th and 19th centuries. Larger governments—the US as a whole, the European Union—reflect a world in which travel and communications are easier. The problems we have today are primarily either local, at the scale of cities and towns, or global—even if they are currently regulated at state, regional or national levels. This mismatch is especially acute when we try to tackle global problems. In the future, do we really have a need for political units the size of France or Virginia? Or is it a mixture of scales that we really need, one that moves effectively between the local and the global?
As to other forms of democracy, we discussed one from history and another made possible by today’s technology.
Sortition is a system of choosing political officials randomly to deliberate on a particular issue. We use it today when we pick juries, but both the ancient Greeks and some cities in Renaissance Italy used it to select major political officials. Today, several countries—largely in Europe—are using sortition for some policy decisions. We might randomly choose a few hundred people, representative of the population, to spend a few weeks being briefed by experts and debating the problem—and then decide on environmental regulations, or a budget, or pretty much anything.
Liquid democracy does away with elections altogether. Everyone has a vote, and they can keep the power to cast it themselves or assign it to another person as a proxy. There are no set elections; anyone can reassign their proxy at any time. And there’s no reason to make this assignment all or nothing. Perhaps proxies could specialize: one set of people focused on economic issues, another group on health and a third bunch on national defense. Then regular people could assign their votes to whichever of the proxies most closely matched their views on each individual matter—or step forward with their own views and begin collecting proxy support from other people.
This all brings up another question: Who gets to participate? And, more generally, whose interests are taken into account? Early democracies were really nothing of the sort: They limited participation by gender, race and land ownership.
We should debate lowering the voting age, but even without voting we recognize that children too young to vote have rights—and, in some cases, so do other species. Should future generations get a “voice,” whatever that means? What about nonhumans or whole ecosystems?
Should everyone get the same voice? Right now in the US, the outsize effect of money in politics gives the wealthy disproportionate influence. Should we encode that explicitly? Maybe younger people should get a more powerful vote than everyone else. Or maybe older people should.
Those questions lead to ones about the limits of democracy. All democracies have boundaries limiting what the majority can decide. We all have rights: the things that cannot be taken away from us. We cannot vote to put someone in jail, for example.
But while we can’t vote a particular publication out of existence, we can to some degree regulate speech. In this hypothetical community, what are our rights as individuals? What are the rights of society that supersede those of individuals?
Personally, I was most interested in how these systems fail. As a security technologist, I study how complex systems are subverted—hacked, in my parlance—for the benefit of a few at the expense of the many. Think tax loopholes, or tricks to avoid government regulation. I want any government system to be resilient in the face of that kind of trickery.
Or, to put it another way, I want the interests of each individual to align with the interests of the group at every level. We’ve never had a system of government with that property before—even equal protection guarantees and First Amendment rights exist in a competitive framework that puts individuals’ interests in opposition to one another. But—in the age of such existential risks as climate and biotechnology and maybe AI—aligning interests is more important than ever.
Our workshop didn’t produce any answers; that wasn’t the point. Our current discourse is filled with suggestions on how to patch our political system. People regularly debate changes to the Electoral College, or the process of creating voting districts, or term limits. But those are incremental changes.
It’s hard to find people who are thinking more radically: looking beyond the horizon for what’s possible eventually. And while true innovation in politics is a lot harder than innovation in technology, especially without a violent revolution forcing change, it’s something that we as a species are going to have to get good at—one way or another.
This essay previously appeared in The Conversation.