Today, security alerts are managed by humans

BlastRadius

blastradius

requires no introduction, as it stands as the undisputed king of Continuous Integration. Over the years, it has adapted to all the technological disruptions in the industry, including . Jenkins Kubernetes This blog post delves into an intriguing topic: how to execute on-demand slaves in a remote AWS Fargate cluster from a Jenkins master instance. For those wondering why such a capability is necessary, the following sections will elucidate not only the reasons but also the methods and associated advantages. Everything is remote! Imagine this: you're running cloud-native services on AWS EKS, and as the diligent engineer that you are, you establish two distinct clusters—one for production and another for all non-production purposes. You might be wondering why you would undertake such an approach. Here's a hint: consider the blast radius. If you prioritize the security of your cloud-native services as fervently as we do at NimbleWork, this decision makes sense. The dev cluster operates, among other things, all our Continuous Integration and Delivery tools. Speaking of Continuous Delivery, we run nightly pipelines that test the services for performance, security vulnerabilities, and regression before deploying them to the production cluster. In the production cluster, we adhere to a blue-green deployment model. This entails the Jenkins master, which operates on the dev EKS cluster, to run slaves on the production EKS cluster for various deployment, management, and general housekeeping tasks. Having outlined the reasons for this setup, let's delve into the details of how it is accomplished. Prerequisites This post assumes you have a running AWS , either on Fargate or Worker Nodes. You can refer to this for creating a Fargate cluster or for Worker nodes if you don’t have them handy. The next step is to install Jenkins on Kubernetes, you can refer to this in their official documentation for this. Since we’re configuring Jenkins slaves to run on AWS Fargate, install the Kubernetes Plugin in Jenkins. EKS cluster article this page Serverless Jenkins Slaves Configuring Kubernetes Connection in Jenkins Master Kubernetes cluster can be configured from the Manage Nodes and Clouds option on the Manage Jenkins Page. Navigate to `Manage Jenkins > Clouds > New Cloud` to open the Cloud configuration page Add a name for the cloud, choose Kubernetes in the Type section, and click on "Create” to create the cloud configuration Expand the Kubernetes Cloud details dropdown, this is where we will configure Jenkins master access to the AWS Fargate Cluster. Kubernetes URL Here we add the public API Server URL of the AWS Fargate Cluster. Log in to the AWS Management Console and select Elastic Kubernetes Service, click on the clusters link to list all clusters in your account, and then click on the name of the cluster you want to connect Jenkins with to reach the overview page. Copy the API Server URL from the highlighted section in the image below and paste it to the Kubernetes URL field in the cloud configuration page in Jenkins. Alternatively, you can get the same information by using the command line too. kubectl Point to your EKS cluster: export AWS_ACCESS_KEY_ID="KEY_ID_HERE"
export AWS_SECRET_ACCESS_KEY="ACCESS_KEY_HERE"
export AWS_SESSION_TOKEN="SESSION_TOKEN_HERE" 

aws eks update-kubeconfig --region us-east-1 --name mycluster then run the commands as follows: kubectl kubectl cluster-info
Kubernetes control plane is running at https://XXXXXXXXXXXXX.gr7.us-east-1.eks.amazonaws.com Kubernetes server certificate key We’ll be using a Kubernetes Service Account to authenticate to the API Server. Perform the following steps on the AWS EKS cluster to enable Jenkins access. Create a namespace associated with the Fargate profile jenkins-jobs Create a service account named in the namespace jenkins-service-account Create a secret token named in the namespace associated with the service account jenkins-token Create a role-binding providing the service-account ClusterRole admin in this namespace. jenkins-jobs you can achieve this in multiple ways, via the Management Console or AWS CLI, we like to stick to IAC in NimbleWork so here’s a sample terraform snippet for the same: resource "kubernetes_service_account" "jenkins-service-account" {
  metadata {
    name      = "jenkins"
    namespace = "jenkins-jobs"
    labels = {
      "app.kubernetes.io/name" = "jenkins"
    }
  }
  secret {
    name = "jenkins-token"
  }
  depends_on = [module.fargate-profile]
}

resource "kubernetes_secret" "jenkins-token" {
  metadata {
    name = "jenkins-token"
    namespace = "jenkins-jobs"
    labels = {
      "app.kubernetes.io/name" = "jenkins"
    }
    annotations = {
      "kubernetes.io/service-account.name" = "jenkins"
    }
  }
  type = "kubernetes.io/service-account-token"
}

resource "kubernetes_role_binding" "jenkins-role-binding" {
  metadata {
    name      = "jenkins-role-binding"
    namespace = "jenkins-jobs"
    labels = {
      "name" = "jenkins-role-binding"
    }
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "admin"
  }

  subject {
    kind      = "ServiceAccount"
    name      = "jenkins"
    namespace = "jenkins-jobs"
  }

  depends_on = [kubernetes_service_account.jenkins-service-account]
} Let’s retrieve the certificate key now, run the following command to get the service account certificate key and token % kubectl get secret jenkins-token --namespace=jenkins-jobs -o yaml The output contains and ca.crt token apiVersion: v1
data:
  ca.crt: XXXXXXXXXX
  namespace: XXXXXXXXXXXXXX
  token: XXXXXXXXXX
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: jenkins
    kubernetes.io/service-account.uid: XXXXXXXXXXXXXX
  creationTimestamp: "2023-05-20T17:25:16Z"
  labels:
    app.kubernetes.io/name: jenkins
  name: jenkins-token
  namespace: jenkins-jobs
  resourceVersion: "3388"
  uid: XXXXXXXXXXXXXX
type: kubernetes.io/service-account-token the value is encoded, decode it via the command and paste the resultant value into the Kubernetes server certificate key field. ca.crt base64 base64 -d Kubernetes Namespace Enter the value here jenkins-jobs Credentials Click on Add > Jenkins and choose the Secret text in the Kind dropdown list of the Credentials provider pop-up, then add the base64 decoded value of the from the  output of the command above to create the credentials. token kubectl get secret Click on the Test Connection button and you’ll see the message Connected to Kubernetes v1.28-eks-XXXXXXX When successfully connected! Pod Template and Retention Add the following values to Pod-Template and Retention settings Click Save to finish adding the cloud. Using the Kubernetes Cloud in Pipelines Now that we have the Jenkins configuration in place let’s look at defining builds to run via Fargate Pods as slaves. We’re using the declarative pipeline syntax here. The pipeline job DSL Groovy should mention the  configured cloud name as follows: agent {
    hackernoonkube {
      yamlFile 'builder.yaml'
    }
  } Add the labels defined in the POD template section above to run the job in a Jenkins slave running as a Fargate Pod.

The Serverless CI - Running Jenkins Slaves on AWS EKS Fargate

In today's rapidly advancing world, it is imperative to embrace the latest technologies in order to craft systems that are scalable, reliable, maintainable, and portable. However, this approach often leads to reactive designs that are not adaptable to evolving needs. System design should be driven by requirements, not by technology.  Achieving a successful system design calls for a profound understanding of both architecture and business requirements, ensuring that the resulting solution aligns seamlessly with the intended goals. For instance, when designing a system to handle 10 million daily requests with 20 ms latency, it's tempting to opt for , database sharding, and highly distributed cloud infrastructure. While these choices may work, they often overlook the importance of employing architectural design principles. Microservices architecture A prime example of this system is "Stack Overflow," which is built on a monolithic architecture. Its success stems from a profound technical understanding and the utilization of software architecture principles. The key point here is that fundamental design choices determine the system's trajectory. Architects gravitate towards the latest technologies or attempt to implement a multitude of design principles to achieve scalability. Like patterns:  DDD, EDA, Microservices, serverless, CQRS, layered architecture, and design principles: , Principle Of Least Astonishment, DRY, Explicit dependency, etc SOLID While architects aspire to implement these principles, in reality, architects are often constrained by time, resources, and urgency, and the evolving business and technology landscape may not always provide an opportunity to rebuild and implement the best architecture choices. This is why it is crucial to design systems based on fundamental design principles. Separation of Concerns This article highlights the importance of one of the core architectural principles that establish the very foundation for achieving success and facilitate the implementation of other architectural principles. The principle states that a system should be built on top of manageable components, with each component addressing a specific concern while minimizing overlap. A successful SoC implementation requires clearly defined component responsibilities, clearly bounded contexts, well-defined interfaces, loose coupling, and high cohesion. Enablers for SoC include SOLID Principles, Message Queues, Event Bridges, state management constraints, API gateway, and Streaming platforms. SoC is THE most important architectural principle as it allows your architecture to evolve over time to support both technology and business vision. Some major advantages of this architecture include: Promotes Modularity Reduce blast radius Enable Faster time to market Enhances  Maintainability, Scalability, and durability Improves Data Quality Enable evolving architecture and modernization like Cloud Migration, Containerization, Event streaming, etc. This principle is applicable to any system, whether it's legacy or modern: Monolith, Microservices, SOA, Enterprise IT, SaaS applications, traditional web applications, backend engines, or analytics platforms. Consider SoC as the foundational design pattern for any system. A system lacking SoC will have poor extensibility and hinder future architectural evolution How Twitter Monetization offering embodies this principle The architecture of is built upon several components, each with clearly defined capabilities and boundaries. It serves as a good reference for large-scale systems built using the principle of Separation of Concerns, coupled with high-performance infrastructure to support high throughput, availability, and low latency, as demonstrated by their "Manhattan" infrastructure. Twitter Some major components and Services include: Timeline Mixer Ad Mixer Onboarding Service People discovery Prediction service Recommendation and Analytics Engine Search Service Indexing and MapReduce And some technology choice that enables scalability Storage - Hadoop, Manhattan, Vertica, flockDB Cache  - Redis and Memcache Events Processing - Kafka, TimeSeries Aggregator (TSAR) For deep dive into Twitter’s infrastructure please refer to: The infrastructure behind Twitter's scale Processing-billions-of-events Manhattan So how does the principle of Separation of Concerns benefit Twitter? Application modernization: Retire Timeline Mixer with a more advanced Home Mixer service. Deliver value sooner: Twitter subscription service for content creator Let’s understand how Twitter might have delivered this service faster using the SoC architecture principle. High-level Requirements The requirement has the following broad features Capability: Offer Monetization for content creators Features: Content creators : Enable monetization, receive payments, send exclusive tweets, view exclusive tweets on user timelines Subscriber: Subscribe to a creator, Make payment, View exclusive posts on home timeline Payment gateway: Collect payment methods and process payment : The architecture below demonstrates how these components are orchestrated to build the desired capability. High-Level architecture Build & Development Based on existing Twitter architecture, following major services might have been modified Timeline Mixer Author timeline - view exclusive tweets in a separate section User home timeline - view exclusive tweets in a separate tab Publisher Service Persist and cache exclusive tweets Graph service Fetch subscription information for building follower graph Security and access control Control who can view/retweet a post Major components to build: Payment gateway: For this phase, Twitter used Stripe but maybe in the future Twitter will build its own Payment gateway service Subscription service: Enable Monetization Persist subscription information Integrations to existing services and data store How did this architecture benefit Twitter? Time to Value Build components independently without impacting existing stack Separate teams can build/test each components for faster build New component can be build on pilot infrastructure and scaled independently based on adoption Reduce blast radius By separating concerns into distinct modules or components, failures or errors within one module are contained and do not affect other modules. Isolation limits the blast radius and prevents widespread system failures. Enable evolvability The architecture allows for evolution over time to accommodate changing requirements. For example, the payment gateway can be replaced with a custom-built gateway without impacting the overall stack. Future services can be integrated or built to further enhance capabilities. this article emphasizes the significance of building software systems based on fundamental design principles, with Separation of Concerns being the most critical principle. The example of Twitter showcases how applying this principle contributes to successful system design, enabling scalability, maintainability, and adaptability to evolving business and technological landscapes. In conclusion, What's not covered in the article? Twitter Specific technology stack: Manhattan, Gizmoduck, Apache storm, Lucene, Redis, graphql, etc. Detail on various Twitter services mentioned above Architecture styles: Domain-driven design, Microservices pattern, Event-driven architecture, CQRS, etc Please feel free to reach out if you have any questions!

The Core Principle of Separation of Concerns & Twitter's Value-Driven Approach

With , AWS IAM usage is on a scale that is often hard to comprehend. Combine that with AWS still maintaining its majority share of the cloud market, it's fair to say a good chunk of the internet is regulated by IAM roles and policies. more than 400 million operations per second With that being the case, you can be confident that AWS has a depth of expertise and wisdom backing up IAM. But it doesn't make managing IAM roles less of an arduous task. Often it means spending your time scrolling through multiple lines of JSON entries, which isn't exactly the most efficient way to look at permissions. The problem is only made worse in large organizations with several accounts and multiple services. It can be an uphill battle to keep track of all the permissions assigned to different IAM roles, making assigning the correct permissions a challenge if you don't know your resources and services like the back of your hand while also making retrospective tasks such as auditing time consuming as you struggle to get the context you need to make important decisions. Working with IAM roles Auditing roles There are a number of different reasons why you’d need to audit IAM roles. As part of a new project to ensure that no unused roles haven’t been created and forgotten. As part of compliance, ensuring you meet regulatory requirements. Or even as part of a security or cost review. Ensuring that unused roles are cleaned up and users have the appropriate level of access is vital and can also help ensure users are held responsible for their actions. In AWS To do this, you can check the last time each role made a request to AWS and use this information to determine whether the team is using the role. You want to gather more information about the role’s access patterns to determine whether you ought to delete it. From the role detail page, navigate to the Access Advisor tab and investigate the list of accessed services and verify what the role was used for. In the Access Advisor tab, you can investigate the list of accessed services and verify what the role was used for. This can also be done via the CLI: $ aws iam generate-service-last-accessed-details --arn arn:aws:iam::1234567:role/role-name
{
    "JobId": "10c3dc31-6ccc-69d2-1185-91e9ad363831"
}

$ aws iam get-service-last-accessed-details --job-id 10c3dc31-6ccc-69d2-1185-91e9ad363831
{
    "JobStatus": "COMPLETED",
    "JobType": "SERVICE_LEVEL",
    "JobCreationDate": "2023-04-25T12:28:18.712000+00:00",
    "ServicesLastAccessed": [
        {
            "ServiceName": "AWS Security Token Service",
            "LastAuthenticated": "2023-04-25T11:49:09+00:00",
            "ServiceNamespace": "sts",
            "LastAuthenticatedEntity": "arn:aws:iam::944651592624:role/aws-source-pod",
            "LastAuthenticatedRegion": "eu-west-2",
            "TotalAuthenticatedEntities": 1
        }
    ],
    "JobCompletionDate": "2023-04-25T12:28:20.485000+00:00",
    "IsTruncated": false
} The question often remains, is this information enough to make important decisions? For example: Can I remove this IAM role that has not been used in 89 days? What happens if it is part of a service that is used every 120 days? How can I be sure that I can remove a role that has no activity? I know the role was used, but which AWS resource used it? A lambda function? An EKS pod? Context is key.. but often missing What’s missing in both the above questions is context. Context of the role and if it is linked to anything. The problem with context is that it is often difficult to get without years of experience or up-to-date CMDBs/documentation. A solution with Overmind Using Overmind does not require any of the above. In fact, it was built to be used with no prior context. You can simply search for what you want, in this case, ‘iam-role’. Overmind will do the work of finding them even across multiple regions and accounts. From here we can quickly distinguish any unused roles or policies because they won’t be linked to any other resources. For example, an unused role will look like this. Whereas one that is currently in use will have links to other resources. In Overmind you can expand out and discover what other resources it is linked to or being used by, providing us with the context we were missing before. From here we’ll be able to understand what this application is and the resources it needs to work out — Answering the question of what the impact would be if we were to remove these roles or policies. Now we have the missing context, we can go ahead and proceed confidently knowing that our changes won’t have any unintended impact. We aren’t stopping here.. What if before making an application change, Overmind could work out the blast radius and inform you of the impact? Or after an unsuccessful change, you could go back and see a snapshot of what your application looked like before? Across all your AWS resources. That’s what we are building and we would love you to join us on this journey. Add your name to our waiting list to register your interest → https://overmind.tech

Confidently Working With IAM Roles in AWS

Hey there. I'm Mrinal Wadhwa, CTO at . I met some lovely old friends and many amazing new people at the RSA Conference last week. Ockam On Tuesday afternoon, I walked through the bustling expo floor with hallway after hallway of products that keenly monitor, scan, and scrutinize every event, every log message, and every asset to detect and thwart any suspicious behavior as soon as possible. It was a stark reminder that the cybersecurity industry has devolved into a game that is impossible to win. We’re about to see major disruption. The Sisyphean Whack-A-Mole One booth had an arcade-like whack-a-mole game (see image above) to help visualize what they do. This is a pretty good illustration of what most (maybe greater than 90%) of cybersecurity products do; they scan some part of your vulnerability surface to detect anomalous behavior. Some scan network traffic, some monitor endpoints, and others inspect API requests. They’re all looking to whack that next mole - as fast as possible. There are thousands of products that specialize in scanning specific corners of your vulnerability surface. Some specialize within a specific industry, others are tuned for logs from specific popular tools. Many are incredibly sophisticated and use advanced machine learning and AI to detect bad behavior. They all highlight that they can whack-a-mole with higher accuracy than their competitors. Most scanning products do the job as advertised. Hey, it is incredibly satisfying to whack moles. But, if we take a step back to look at trajectory, we notice that our vulnerability surface is growing way faster than we can build scanners to monitor every part of it. Our personal and business data is, paradoxically, becoming less secure over time. Like Sisyphus, from Greek mythology, our industry is endlessly rolling a big boulder up a steep hill only to watch it roll back down. Our vulnerability surface is growing exponentially To develop an intuition, stay with me as I do some napkin math about an example application and the vulnerability surface of data it manages for users. For the purpose of illustration, assume that the odds of any one person making a bad security decision is a fixed constant. With a development team of 10 people, the vulnerability surface created by the application's would have an area of . source code 10 If this app depends on say 100 libraries and each library has 5 developers, then the area of the vulnerability surface created by these libraries is 100 * 5 = 500. Assuming the app runs in a container that has 100 operating system packages and each package has 5 devs, then the area of the vulnerability surface created by OS packages is also 100 * 5 = 500. Together, create a vulnerability surface of 500 + 500 = . dependencies 1000 This example app would operate in some network and that , let’s say, has 9 other microservices in it. If each service has a similar-sized team and dependency tree, then total vulnerability surface area of our app’s data becomes 10 * 1000 = . network 10000 Our app also depends on 9 cloud-based services (Databases, Event Streaming, Gateways, etc.) and each third-party service similarly is made of 10 microservices operating in a network. Total vulnerability surface area of our app’s data becomes including becomes 10 * 10000 = . third-party services 100000 This napkin math, while it ignores overlaps across surfaces, is a good mental model for the of the problem facing typical modern applications - . exponential scale Tens of thousands of developers, platform engineers, and system administrators must never ship a mistake for our example application’s data to remain secure ; we’ll never build enough scanners to catch all possible mistakes that can be exploited by attackers. Vulnerability surfaces are too big and are growing too fast. This is untenable To make matters even more challenging, a typical application development team has limited control over most of the vulnerability surface described above. They can’t choose to not use open-source libraries or not rely on cloud services. Building everything from scratch will take too much time, cost too much money, and will likely result in poor-quality solutions. We must change the game Instead of attempting to scan every part of an exponentially expanding surface, the only tenable approach is to make design choices that completely eliminate large portions of our vulnerability surface. We have to make entire classes of attacks impossible. We must build software in ways that drastically reduce the size of potential targets and limit the blast radius. Our . software must become private and secure by design In the past, this was challenging and costly. The following tools are changing the game: like Rust and Typescript turn invariants into compile-time errors. This reduces the set of possible mistakes that can be shipped to production by making them easier to catch at build time. Strongly typed languages of buffer overflows, use-after-free, and other memory safety errors. An attack vector that is known to cause 60-70% of high-severity vulnerabilities in large C or C++ codebases. Rust provides this safety without the performance costs of garbage collection at runtime. Memory-safe languages eliminate the possibility Supply chain security practices described in emerging standards like SLSA help us build controls that . This diminishes the possibility of malicious libraries, packages, and container images exploiting developer workstations, build pipelines, and runtime environments. guarantee artifact integrity within our dependency trees , stored in secure hardware, combined with and approaches eliminate the possibility of attacks using stolen passwords and access tokens. Cryptographic keys passwordless tokenless and granular , at the application level, using tools like Ockam, enables zero trust in operating networks, VPNs, and VPCs. This removes other applications within the same network from an application’s vulnerability surface. Mutual authentication authorization of all data, and using Ockam , services from our vulnerability surface. End-to-end guarantees of data authenticity, integrity, and confidentiality mean that any mistake or misconfiguration within a broker, load balancer, or gateway cannot compromise our application’s data. Application layer, end-to-end encryption Secure Channels eliminates third-party All these approaches shift security left and allow an application’s development team to be in control of the security and privacy properties of their application. This team no longer has to cross their fingers and hope a third-party service won’t be compromised; they can simply end-to-end encrypt data as it passes through that service. Such design decisions turn security and privacy into problems that can be methodically solved instead of endlessly rolling a big boulder up a steep hill. Regulatory pressures are forcing the game to change Another interesting effect of relying on scanners for security is that it shifts the costs of securing software, away from vendors, to the customers of software. In the past, software vendors were able to require that customers operate their software within tightly controlled network boundaries like VPNs. They were able to specify environmental configurations that must be set up just right for their products to be secure. They were able to pass the costs and liabilities of security to their customers. As security threats escalate and vulnerability surfaces become unmanageable, both customers and regulators have realized that this shift of burden is ineffective and too expensive. The chief executive at insurer Zurich recently told the Financial Times that ”. CISA chief Jen Easterly and her colleague Eric Goldstein penned an article in February titled - arguing - They lay the to a model where cyber attacks may become “uninsurable Stop Passing the Buck on Cybersecurity “Technology manufacturers need to take responsibility for the security outcomes of their customers.” plan for a foundational shift “cybersecurity would ultimately be the responsibility of every CEO and every board.” This shift of accountability to senior leadership at technology vendors is reflected in new regulations across countries. For instance, the SEC has proposed cybersecurity incidents within . rules that require companies to disclose four business days In this turbulent landscape, savvy businesses are turning security and privacy into a competitive advantage. Software products that are designed to be secure are winning customers because they result in much safer systems that remove risks, ease compliance hurdles, and are significantly cheaper to operate. As I walked out of the expo halls at RSAC, it was obvious to me that the cybersecurity industry is about to see some disruptive change and the only companies that will survive the next few years are the ones that embrace this new reality.

A CTO’s Reflection of the 2023 RSA Conference

Ockam launches Orchestrator, the first developer tool that can add end-to-end encryption between any application, allowing them to trust data-in-motion. We all use WhatsApp and Apple Message to secure the personal messages that we send to each other. It's a bit of an unspoken truth – whether it's the blue bubble message on your iPhone, or the double check in your WhatsApps – when you receive confirmation of delivery or receival, you know those messages were delivered safe and secure. These messaging services also provide each of us with personal privacy and trusted encryption that ensures that each message received is from who we are messaging with. This level of personal encrypted messaging ensures that no one can intervene in our conversations - not even Apple or Facebook, who manage and run each of these services. You these messages. Trust The reality is, the rest of the data that moves through the internet is not as fortunate. Enterprise apps holding financial, health, personal, and corporate data do not have a 'WhatsApp' or 'Apple Message' level of - and historically there has not been a drop-in service that comes with the same guarantees and safety that personal messaging apps have. Why is this? It's because secure messaging systems are exceptionally difficult and very expensive to build. Only elite engineering teams with massive budgets and long timelines can build these systems reliably. Trust In the Enterprise space, this same messaging scenario plays out every day for millions of applications – regardless of the industry. Modern cloud applications run in numerous private networks. The data that moves between networks is passed through an unwieldy number of intermediaries - any of which could break the chain of trust that connects applications together. The security surface area of modern cloud applications is impossible for a team to control. Developers need the ability to build applications that are able to move data across complex, variable, and hostile networks. And, in a world where trust, privacy, and security is more important than it's ever been, it's crucial that businesses ensure that those apps have secure, authenticated, and private connections to their data. Our mission at Ockam is to empower every developer at every business with the simple tools they need to create applications that can . That's why we're so excited to share that Ockam Orchestrator is now generally available, democratizing the ability for anyone to build . Trust Data Trust for Data-in-Motion Introducing the General Availability of Ockam Orchestrator Ockam Orchestrator is the fully-managed cloud service that Enterprise developers need to build trust between applications, collaborate with teams, integrate with automated infrastructure, connect with data-layer stores and message brokers, and to facilitate massive scale message exchanges. Ockam was built by developers for developers, allowing them to build apps with end-to-end data integrity and authenticity. The general availability of Orchestrator means developers can now leverage new features and functionality to help leverage Ockam's suite of tools and programming libraries to orchestrate end-to-end encryption, mutual authentication, key management, credential management, and authorization policy enforcement – all at massive scale. Ockams's features include: Trust at the Application Layer Cryptographic identities and authentication everywhere. Managed credential authorities and ABAC. Enrollment protocols that bootstrap. BYO identity providers and access control policies. End-to-End Encryption for Data-in-Motion Through networks, clouds, and protocols. Over enterprise messaging and event streams. For existing and new infrastructure. Built for high-throughput, low-latency, and high-availability. Open and adaptable Open Source. Add-ons for Confluent, InfluxData, Okta, KMS, UDP, and more. Developer experience Tools and packages. SLAs and Support. Build secure-by-design applications that can Trust all Data-in-Motion. Ockam's suite of developer tools, programming libraries, and managed cloud services shift security left by empowering developers to create apps that can Trust Data-in-Motion and that have end-to-end guarantees for data authenticity, integrity, and confidentiality. Ensuring peace of mind for developers starts with providing the right tools and services to allow developers to focus on building applications without worrying about trusting data-in-motion and thinking through every detail that ensures that those apps are private and secure-by-design. In order to trust the data that they receive, applications need the end-to-end guarantees of data authenticity, integrity, and confidentiality. Secure-by-design applications minimize their vulnerability surfaces and have 'zero-trust' in the networks that they connect to. In doing so they shrink both the target and the blast radius of security breaches. Underlying all of Ockam is a variety of well-researched and advanced cryptographic and messaging protocols from the applied and academic cryptography communities. So that anyone can use protocols, we've made them safe and easy to use in any application. It also means that we've made them very difficult to misuse! Ockam takes the guesswork out of this process by handling all of the underlying protocol complexity and provides developers with high-level and composable building blocks to create end-to-end, application-layer trust in data. Ockam Open Source brings collaboration, trust, and security to apps. Ockam's products are all built from , which is available under the Apache License 2.0 on GitHub. We believe that all security products should be based upon open source code, because the more people that can review, audit, and contribute to a code base, the more secure it becomes. Ockam Open Source Ockam Open Source was built with the Rust programming language. Ockam chose Rust because of the security and trustworthiness properties of the language. Rust is highly performant, is memory safe, and was designed to prevent common errors that occur in programming. Over 200 engineers have contributed to the Ockam Open Source project, to date, and it is one of the fastest growing projects and communities in the security space. , Source #1 Source #2 Want to learn more? Check out Ockam Orchestrator in action See how Ockam's customers are using our products Get in touch Also published . here

Ockam launches Orchestrator for Enterprise-grade Trust of Data-in-Motion

Ockam lanza Orchestrator para la confianza de datos en movimiento de nivel empresarial

Ockam lance Orchestrator pour la confiance des données en mouvement de niveau entreprise

ओकाम ने डेटा-इन-मोशन के एंटरप्राइज़-ग्रेड ट्रस्ट के लिए ऑर्केस्ट्रेटर लॉन्च किया

Ockam は、Data-in-Motion のエンタープライズ グレードの信頼性を実現する Orchestrator を発表します

Ockam lança orquestrador para confiança de dados em movimento de nível empresarial

Ockam ra mắt Orchestrator cho độ tin cậy cấp doanh nghiệp của Data-in-Motion

Ockam 推出 Orchestrator 以实现企业级动态数据信任

Privacy Matters In this age of data-first organizations, no matter what industry you’re in, you’re most likely collecting, processing, and analyzing tons of customer data. It could be for fulfilling a customer’s service request, for legal or regulatory reasons, or for providing your customers with a better user experience through personalization using artificial intelligence or machine learning. However, data breaches are increasing every year, with 1862 reported data compromises in 2021, up 68% compared to 2020, with 83% of those involving sensitive information (as per Identity Theft Resource Center). Such sensitive information falling into the wrong hands could wreak havoc on the customer’s life due to identity theft, stalking, ransomware attacks, etc. This coupled with the rise of privacy laws and legislations across various states has brought privacy-enhancing data processing technologies to the forefront. Privacy vs data utility tradeoff With AI applications such as personalization, privacy, and data, utility can be visualized on opposite sides of the spectrum. Data that doesn’t contain anything personal i.e., expose no traits or characteristics of the customers, lend no value for personalization. However, data containing personal information can be used to deliver highly personalized experiences but if the dataset ends up in the hands of any human, it can lead loss of customer data privacy. As a result, there is always an inherent tradeoff between privacy risk and the utility of that data. Value of being privacy-first for organizations Health Insurance Portability and Accountability Act (HIPAA), California Consumer Privacy Act (CCPA), Children’s Online Privacy Protection Act (COPPA), and Biometric Identifier Act are just a few of the many privacy-centric laws and legislations in the US. Failure to comply with such regulations can cost an organization billions of dollars in fines. For example, recently the state of Texas sued ’s parent company Meta for billions of dollars in damages for mishandling and exploiting the sensitive biometric data of millions of people in the state. Facebook Being privacy-first can help avoid huge fines, more so you can lose your license to operate as a business. In addition, there can be a massive loss of consumer trust and loyalty, brand image, and perception. Being negligent with consumers’ data privacy can demolish customer lifetime value, and affect conversions and renewals. In fact, companies like have flipped the problem on its head and are using privacy as a competitive moat; a differentiator from other technology companies. Apple Sources of Privacy Risk in data collected by an organization There are three key sources of privacy risk within an organization: Raw customer data and any of its derivatives. Raw customer data can be customer-entered data such as name, address, age sex, and other profile details or data on how a customer is using the product such as page visits, session duration, items in cart, purchase history, payment settings, etc. Metadata and logs. Metadata and logs include the location of customers, the website a product was accessed from, the IP address of the device, MAC address, service logs, logs of calls with customer support, etc. ML models that have been trained on customer data. ML models themselves can seem like they don’t contain anything personal, but ML models can memorize patterns in the data it has been trained on. Models trained on critical customer data can retain customer-attributable personal data within the models and present customer personal data exposure risk regardless of whether the model was deployed in the cloud or on edge devices. If a malicious actor gains access to such a model, even as a black box, they can run a series of attacks to recover the personal data leading to a privacy breach. An ML model’s security classification should be determined based on the data classification of its training data. ML model artifacts can contain plaintext customer data and the ML model itself is susceptible to privacy attacks. If an organization is running a marketplace and sharing ML models with external partners, even under NDA and data-sharing agreements, ML models present a high risk of privacy attacks. How to identify the gaps Here are a few strategies to identify the biggest gaps and start using Privacy Enhancing Technologies (PET) to close the gaps: chart the customer data lifecycle across your organization, right from data collection or ingestion to storage, usage to deletion. A chart will help you visualize the end-to-end flow and formulate an effective strategy for the whole organization. Follow the data: Identify the humans, processes, and systems that have access to customer data. Where are the humans in the loop, and is it a business requirement for them to have access? Also, what are the tools used to access data, and how? Create a threat map: for each use case, think about the likelihood of a privacy-risk event and estimate the blast radius and categorize each threat as high, med, and low severity Identify the use cases: start with the high-risk items first, regularly measure progress and make your way down the list till all the risk items are low. Identify the drivers and define goal success criteria: Privacy Enhancing Technologies Privacy Enhancing Technologies is an area of active research with tremendous advancements made in the last 5 years. Broadly PET can be classified under 2 buckets — data sanitization and privacy-preserving computation. Data sanitization techniques focus on detecting and modifying personal information to de-sensitize it. This includes techniques such as direct identifier detection and removal, Pseudonymization, K-anonymization, and Differential Privacy. Privacy-preserving computation techniques focus on operating on private data but in a closed environment with no humans having access to it. This includes techniques such as , [secure multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation#:~:text=Secure%20multi%2Dparty%20computation%20(also,while%20keeping%20those%20inputs%20private.), , and trusted execution environments (TEE). One of the most efficient ways of managing privacy risk is by doing all the processing on the edge device itself. This mitigates the biggest risk of customer data leaving their device, especially for consumer applications, and has the added benefit of giving a hyper-targeted experience in a distributed environment without burning cloud compute costs. The biggest challenge is to prevent overfitting since the volume of data may not be sufficient and affect the quality of predictions. homomorphic encryption federated learning Privacy engineering and Privacy Enhancing Technologies is a rapidly evolving field and the best way to stay up to date is by attending conferences, reading research papers, and joining the open-source community to get the latest updates. Lastly, I recommend starting small with the simple techniques of identifying direct identifiers and removing them before moving to more complex approaches. Also published here.

How to Minimize Privacy Risks in AI/ML applications

Use LaunchDarkly to Quickly Implement Feature Flags

TLDR: VPNs are passe. It's time to upgrade to a Zero-Trust Network (if you haven’t already) If you are an employee who works remotely, I am sure you have been in this situation. You are trying to access a corporate cloud resource from home, but you can't get past the company's VPN. The experience is horrible- it's slow, hard to connect, and once you're finally in, you can't access half the things you need without back-and-forth Slack messages to the IT help desk. On the other hand, if you are an IT professional who manages remote workers, your users are constantly complaining about the VPN, and you are struggling to keep up with requests to add new apps and services to the corporate firewall. You are running around like a chicken with your head cut off, whitelisting IP addresses to maintaining complex subnet assignments and VLAN segments. You are starting to feel like your job is nothing but granting access to different parts of the network- like a medieval castle guard. If this sounds familiar, then you are not alone. In the age of remote work, access management has become one of the most important- and difficult- tasks for IT professionals. Access Control in the Age of Remote Work The problem is that most Access Management solutions were designed for a world where everyone worked in the office. They relied on things like IP addresses and site-to-site VPNs to control access. But in the age of remote work, those solutions just don't cut it anymore. Today, network security and access control are hard. Users are accessing corporate resources from all over the world. It's hard to keep track of all the different devices, apps, and users on your network. It's hard to know what they're doing and where they're going it. And it's especially hard to ensure they're not doing anything that they shouldn't be doing. But it doesn't have to be this way. There is a new class of solutions that are designed for the age of remote work. These identity-first networking solutions use user and device identities to control access rather than IP addresses. Problems With VPNs VPNs were designed for a different era- an era when network security was based on the perimeter. But in the age of remote work, the perimeter has all but disappeared. The first step in moving to an Identity-First solution is understanding the limitations of your current VPN: : VPNs rely on IP addresses to control access. But when users are working remotely, they often don't have a static IP address. This makes it hard to grant them access to the resources they need. Incompatible with remote work : VPNs provide access to entire networks, increasing the blast radius of incursions. Even worse, by publicly exposing an access point into your network, VPN s may give attackers the ability to identify systems and users on your network. Security issues The biggest complaint with VPNs is the poor user experience. Users have to log in, wait for the connection to be established, and then hope they can actually access what they need. In a battle between user experience and security, security will lose every single time. If you make your users jump through hoops to access resources they need for their jobs, they will find (often creative) workarounds to access the data they need. Poor user experience: . As the number of users and devices grows, so does the complexity of managing the VPN. VPNs are difficult to scale : When you have hundreds or even thousands of users connecting to your network through a VPN, it can be difficult to audit and review who is accessing what. Difficulty in audit and reviewing access With a VPN, it's all or nothing. Users have access to the entire network, which makes it difficult to limit their access to only what they need. Lack of granular control: The bottom line is that VPNs are no longer enough to keep your network secure. It's time to move to an identity-first solution. Identity-First Networking vs. Traditional Network Security Identity and Context-Based Access The biggest problem with the traditional network security model supported by a VPN is that it relies on a static perimeter. There is a clear distinction between "internal" and "external" users. Internal users are trusted because they have been physically verified (e.g., they are inside the building), while external users are considered untrusted and are subject to more stringent security measures. With the rise of remote work, the proliferation of mobile devices, and the increasing use of cloud-based applications, the network perimeter has become increasingly porous. It's no longer possible to rely on the network perimeter as a security boundary. In a Zero-Trust Network, there is no concept of "internal" network traffic. All users are treated equally, regardless of location. Access is based on user identity and context, not on an IP address. This makes it much more difficult for attackers to gain access to resources since they would need to have a valid user account and be able to pass both identity and context evaluation. Granular control over resource access While a VPN creates a secure tunnel between two points, it does not provide granular control over who has access to what resources. A Zero-Trust Network, on the other hand, uses identity and context to make real-time decisions about whether to allow or deny access to a resource. Zero-trust principles One of the biggest issues with VPN is that it is incompatible with Zero-Trust. Access is a security model that requires all users, regardless of location, to authenticate before accessing any resources. The model is based on the following principles: Every request to a private resource is authenticated and authorized based on real-time contextual information (user identity, location, device, risk, etc.). Verify before you trust: There is no such thing as an internal network or an external network. All traffic is treated equally and requires verification. Never trust, always verify: Users are identified, and their actions are logged so that you can audit and review them later. Tie users to their actions: Users are only given the bare minimum permissions they need to do their job. No more, no less. Enforce least privilege: Benefits of Zero-Trust Networking There are many benefits to implementing Zero-Trust Networking, including the following: By implementing multiple layers of security, you can make it more difficult for attackers to penetrate your network. Increased security: Zero-Trust Networking can help you meet compliance requirements, such as those set forth by the GDPR and HIPAA. Improved compliance: Zero-Trust Networking provides a better user experience than traditional VPNs, which can be slow and cumbersome. Enhanced user experience: Zero-Trust Networking simplifies network management by eliminating the need to maintain separate "internal" and "external" networks. Simplified network management: Zero-Trust Networking is the future of network security. It provides a more robust and comprehensive security posture than traditional network security models, and it's easier to manage and maintain. It's time to rethink your access control strategy and move to an Identity-First model that will allow you to take advantage of the cloud, improve your users' experience, and increase your organization's security posture.

Guess Who? Access Management Struggles in the Age of Remote Work

, by 2023, 65% of the world’s population will have their personal information covered under modern privacy regulations. In addition to this worldwide legal motion of privacy regulations, consumers themselves are also becoming more privacy-savvy and demanding that businesses protect their personal information. A privacy risk assessment can help companies to answer these two complementing requirements. Let’s dive into the details of what a privacy risk assessment is, why it can benefit businesses, and how to conduct one. According to Gartner What is a Privacy Risk Assessment? A privacy risk assessment is a risk management framework for determining the risk of holding and maintaining PII (Personal Identifiable Information). Organizations can make informed decisions to prevent privacy-related mistakes by conducting privacy risk assessments. This ensures businesses comply with privacy regulations and can accommodate data privacy requests from consumers and authorities. As a result, companies that conduct privacy risk assessments are more likely to avoid legal and business implications of non-compliance and to build long-term, trustworthy relationships with their customers. Privacy risk assessments are often referred to as PIAs (Privacy Impact Assessments) or DPIA (Data Protection Impact Assessments). What does each of these privacy risk assessment types mean? What are PIAs (Privacy Impact Assessments)? PIAs are risk assessments that analyze an organization’s existing privacy controls. By monitoring the organizational processes, systems, applications, and products, a PIA determines to which extent PII is managed and secured and the extent of the business’s privacy risks when collecting, maintaining and circulating PII. This internal audit enables organizations to take action and resolve any blind spots by implementing actionable steps, for example, by adding privacy policies, enabling consumer opt-out, enforcing data encryption, etc. Businesses often run PIAs when they implement a new business initiative. Initiatives might range from a project as small as a new product launch to as large as an M&A. What are DPIAs (Data Protection Impact Assessments)? DPIAs are also risk assessments. However, unlike PIAs, they are connected to the . Article 35 of the GDPR requires businesses to develop and run DPIAs for high-risk data process activities. GDPR This includes the following use cases: Profiling and other types of evaluations of personal identifiable aspects Large-scale processing of personal information and personal identifiable information Data collection and processing that takes place in an automated manner Surveillance of public areas at a large scale DPIAs are expected to include: A methodical description of data processing activities and their purpose. An analysis of the legal reasoning behind data collection activities. An evaluation of the risk these data collection activities have on individuals. A presentation of the measures the business needs to take to mitigate these risks and ensure compliance with the GDPR. The DPIA framework helps organizations comply with the GDPR and prevent the costly legal and business implications of violating this regulation. Why Businesses Need a Privacy Risk Assessment Privacy risk assessments enable businesses to adhere to modern privacy requirements. These could be either compliance requirements by governmental organizations, consumer requirements demanding businesses to protect their data, or requirements of internal business stakeholders who are aware of the importance of privacy. Let’s break down each one of these requirements: Compliance Regulations - New regulations are sprouting around the world. Legally binding requirements like the GDPR, CCPA, , , and others all require varying extents of personal information management, maintenance, and control. By conducting a privacy risk assessment, businesses can identify compliance gaps, evaluate gaps and their risks and treat them - before suffering from the legal and financial implications of non-compliance. PIPEDA CPA Consumer Requirements - Individuals today are much more privacy-savvy than they were in the past. They know the exposure of their personal information could result in discrimination, personal embarrassment, financial losses, and even physical harm. As a result, they expect businesses to safeguard their personal data. A privacy risk assessment can help companies to build long-term relationships with consumers based on trust. Internal Security Requirements - The threat of a privacy data breach looms over businesses, mainly because it’s hard to anticipate the blast radius. A breach could occur due to a “silly” security overlook like a password (see: SolarWinds) or an innocent leak by an employee but still have a devastating publicized impact. With a privacy risk assessment, the business takes active steps to reduce this risk by identifying security and compliance threats, so it can take action to remediate them. A privacy risk assessment is an opportunity for businesses - to do the right thing for both their customers and to protect their business - and reposition themselves as a privacy-first entity. Benefits of a Privacy Risk Assessment A privacy risk assessment might sound like a daunting and complicated process, but conducting an assessment actually has multiple benefits for businesses, including: Being Prepared - for Anything Privacy risk assessments are strategic initiatives that enable the business to plan privacy activities and prepare for compliance audits and consumer requests so they can prevent any unpleasant surprises. By running them, the company can ensure they are always ready, no matter which privacy curve ball comes their way. In other words, a privacy risk assessment can help avoid unnecessary stress. Making Informed Decisions A privacy risk assessment starts with identifying any privacy gaps in how the business collects, manages, and secures private information like credit card numbers, contact details, credentials, addresses, etc. Then, the assessment evaluates the risk of these gaps and information being leaked. This data-driven and methodical approach enable businesses to make informed and cost-effective decisions regarding how to deal with privacy holes and blind spots. The decisions can be backed up and proven to show the benefit for the business. For example, by comparing the potential damage, a breach could have or by showing the time saved compared to the required process if a violated compliance regulation is found by the government. Signaling to Consumers and Employees Businesses today are subject to lots of pressure. Intense competition, geo-political tectonic shifts, the Great Resignation, and technological changes are just some of the changes keeping business owners up at night. Throughout this turmoil, it is important to maintain a stable and reliable relationship with consumers and with employees, and ensuring their privacy is an important way to do so. Businesses that take action to safeguard consumer and employee personal data signal to them that they are their number one priority. While not every company can afford to run widespread campaigns touting their privacy-first actions, as Apple did, even a pop-up update on the website, an email or text message, or a social media update can do the trick. This will have a beneficial, long-lasting effect. Preparing for Compliance Audits Compliance requirements are strict and mandatory and cannot be treated lightly. A privacy risk assessment ensures no privacy requirements will fall through the cracks. It provides a comprehensive overview of all processes that need to be fixed and gives the business the chance to treat them before they become a legal liability. In addition, a privacy risk assessment provides the company with evidence that it took the required steps on the way to compliance to showcase to the authorities. How to Conduct a Privacy Risk Assessment Despite the importance and value of privacy risk assessments, there is no checklist or single step-by-step process to take when conducting one. There are, however, multiple tools in use by the industry. The main ones are: Data Mapping Data mapping is the process of reviewing, matching, and correlating data fields to create a unified, transparent, and comprehensive overview of where and how data is stored and used in the organization and how it flows within the organization's systems. A data map can include information about the number of data sources, their type, the types of data they contain, data accuracy, data quality, data structure, who has access to the data source, and more. With data mapping, businesses can ensure their data is consistent and of high quality across all sources. This information enables them to identify potential privacy and compliance risks. Once gaps are identified, the remediation process can be streamlined. This helps organizations minimize privacy risks, fulfill regulatory requirements and take control of their data. You can also use a data mapping tool that evaluates your third-party vendors to add an extra layer to your assessment easily. Generating an Automated RoPA A Record of Processing Activities (RoPA) is a record of the privacy procedures and maintenance of these procedures within the organization. A RoPA reveals up to 100% of data sources and presents them in an easy-to-understand manner. An automated RoPA tool will use data mapping to map data flows related to collecting, storing, processing, retaining, and deleting PII. Then, the tool will automatically generate the RoPA report and ensure it is kept updated. With the RoPA, businesses can gain insights into their privacy activities, identify gaps and mitigate them, and be ready for any audit. Manual Assessments A more traditional way of conducting a privacy risk assessment is through the manual collection of data. This includes handing out questionnaires, combing over spreadsheets, and conducting analysis of the results. This process is slow, time-consuming, and inaccurate, and therefore it is not recommended. FAIR Privacy and NIST PRAM Assessments More advanced, albeit still manual, ways of conducting a manual assessment is by using the FAIR Privacy or the NIST PRAM frameworks. Fair Privacy - Based on the FAIR (Factors Analysis in Information Risk) method, Fair Privacy provides a guiding PowerPoint and a spreadsheet for calculating risk based on the Monte Carlo simulation. NIST PRAM - PRAM (Privacy Risk Assessment Methodology) is a series of worksheets designed by NIST to help businesses “analyze, assess, and prioritize privacy risks to determine how to respond and select appropriate solutions.” More details on both frameworks are here. External Assessments An external assessment conducted by a consulting company can take away the heavy lifting of the privacy risk assessment from the business. The vendor will come in, assess all privacy mechanisms and provide recommendations for the next steps for the business to take. When conducting an external assessment, it’s important to evaluate the ROI. This includes the costs of the process, as well as the long-term impact that comes from exposing sensitive data to an external vendor. In addition, it’s recommended to understand the data mapping process the vendor will conduct. Will they run a manual, error-prone process or introduce automated tools and techniques? What happens to your data after the vendor leaves the premises? How often is the assessment updated? And more. Next Steps for Businesses Privacy risk assessments provide early warning for businesses about privacy gaps and their impact, so they can make informed decisions and prevent costly and embarrassing mistakes. To get started we recommend choosing an effective solution that removes the heavy lifting from you and provides an efficient and accurate result that you can quickly and easily act on. provide businesses with an effective and privacy-aware solution that provides insights into their data collection and management. These insights can then be easily translated into actionable steps that bridge any privacy gaps, enabling businesses to comply with regulations, respond to consumer requests and meet internal security requirements. In addition, an automated solution provides businesses with control over the assessment process and their data. Automated data mapping and RoPA report generation Also published . here

A Guide to Conducting Privacy Risk Assessments

GitOps as a practice has been in use since 2017 when Alexis Richardson coined the term. It transformed DevOps and automation. If you look at its core principles, it extends DevOps by treating Infrastructure as Code (IaC). Your deployment configuration is stored in a version control system (a.ka. Git), providing a single source of truth for both dev and ops. As the framework’s adoption increased, in the cloud native space. Many agile teams because of familiarity with git-based workflow for release management of cloud native workloads. GitOps became the standard for continuous deployment adopt GitOps GitOps principles differ from the traditional CI & CD pipeline approach. In the last few years, the GitOps working group under CNCF formalized all the ideas developed around GitOps into a cohesive set of principles that have become . the GitOps Principles Declarative Versioned and Immutable Pulled automatically Continuously Reconciled The uses of GitOps helped organizations in the following aspects: Swifter deployment and more often Fast and easy disaster recovery Effortless credential management Improved developer experience GitOps created a standard practice that allowed engineers to focus on developing solutions rather than figuring out how to deploy them. However, as companies grow, they increase the rate of new features, and the risk of downtime/failures in production also increases. They face problems like the control of blast radius and minimal risk from recent releases. So, is there any way blast radius can be minimized while testing out releases to a subset of users? – Yes, there is a way through Progressive Delivery. Progressive Delivery The term was coined by , who talked about new software development practices beyond continuous delivery. Based on James Governor’s transcript on Progressive Delivery, we want to minimize the blast radius and control the delivery. This could be done by diverting some traffic to new deployment, measuring the success metrics, and then promoting the release to all users. Some of deployment strategies are , , and . What is Progressive Delivery and who coined the term? Progressive Delivery James Governor at RedMonk Canary Blue-Green A&B testing There are a lot of tools that allow us to implement Progressive Delivery. Azure DevOps, AWS App Mesh are the widely used proprietary tools, while ArgoCD and Flux are widely used open source tools. In this blog post, we shall focus on Flux & Flagger, which is an open source tool that is quite popular. Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories) and automating updates to the configuration when there is new code to deploy. What is Flux? is a Progressive Delivery tool that automates the release process for applications running on Kubernetes. Under the hood, both tools are built on top of a modular GitOps toolkit. It is the main reason why Flagger compliments Flux. What is Flagger? Flagger Typical Pipeline Let’s level-set how a CI/CD pipeline works, then we can talk about how Flux and Flagger fit in the picture. In a typical CI/CD pipeline, we push the latest images to the registry and config changes to a repository. Hereon the Ops person will correct the cluster state with the new config changes by applying a new config or upgrading the existing resources in the Kubernetes cluster. This also typically means that the ops person should know the changes that need to be made along with the context of those changes, and hence this manual process quickly becomes error-prone. This whole process also becomes time-consuming and hard to manage. There can be issues that might occur after applying the latest changes. We need to have a solid & spontaneous feedback loop on new releases. What if we could automate the whole process from deployment to production and have proper change management in place for application & infra configuration? Here comes Flux, which helps us automate image tag updates to git and reconciliation of clusters to the desired state as soon as new changes are pushed to the git repository. Flux Let’s put Flux in place to see how we resolve all those issues from a typical pipeline. Source: GitOps Flux is based on the Operator pattern. Operator pattern is software extension to Kubernetes that uses custom resources to manage application components is built on top of Kubernetes API. Installation of Flux Installation of Flux is straightforward. You need to install Flux CLI to run the bootstrapping process. The bootstrapping process will create a repository on GitHub (or any other git hosting service) and all required manifests for installation and connection to the git repository. Follow this doc to . Get started with Flux Reconciliation Flux keeps a constant watch on the changes in your repository. It doesn’t require any event to start the reconciliation loop. It allows you to configure the reconciliation loop at each component. You can have your git checked every 3 minutes and sync in 10 min, allowing you to stagger how reconciliation happens. Automate image updates to Git When Flux comes into the picture, it will start watching your image registry for new updates and push back to git for you. We don’t have to take care of updating the image IDs this time. This feature is not enabled while setting up the Flux. You can follow this . Automate image update to Git - Flux Source: Image reflector and automation controllers | Flux Secret Management Once you adopt GitOps, you need to find a way to manage the secrets that your application might require to communicate to other services within the Kubernetes cluster. You can’t simply store your application secrets inside the git repository, right? You might be thinking of different ways of encryption. For example, you can commit secrets to version control and enable Flux to decrypt them. Flux provides two guides to store secrets through and . Sealed Secrets Mozilla SOPS Application Delivery Unlike other options Flux natively supports Helm and uses native Helm library to deploy helm release onto the cluster. This means you can run on a cluster and it will show exactly how works. helm ls helm install Another important thing is Flux allows you to manage dependencies between HelmRelease CRDs or Kustomization CRDs. It enables you to control the load order of collections/groups of YAML files. It does not maintain the order in which individual YAML files are applied. Promote Release Flux can help you automate the process of promoting the release with GitHub Actions. Source: Promote Flux Helm Releases with GitHub Actions Webhooks Flux is, by design pull-based (i.e, identifies the changes directly from the source ) and good at managing drift in clusters because it is easier to correct the state of a cluster from inside rather than from outside where your tool doesn’t have a correct understanding of the current state of clusters. Suppose you want to make your pipeline responsive as a push-based or faster process. In that case, you can set up webhook receivers on git push that will trigger reconciliation. Alerting and notifications Flux can notify you about the resource statuses change as the health of the new app’s version. You can receive alerts about reconciliation failure in clusters and configure different mediums for reporting - channels such as Slack or embedded in git commit status. This helps inform the developer team whether the new version of the app was deployed and whether it is healthy or not. Source: Flux Slack Error Alerts Source: Setup Notifications | Flux Source: Notification Controller | Flux Authorization Methods Flux relies on the RBAC capabilities of Kubernetes and does not have its own authorization management. It uses Kubernetes RBAC for authentication or authorization. It can be a downside if you want to provide authorization using SSO. User Interface There is no UI for Flux. It does have an that is not in an active development state at the time of writing this. experimental UI Flagger So far, we have automated our delivery process to the cluster with alerts and notifications in case of any failure and unhealthy state of the cluster. Now, we will look at how Flagger integrates into this process and allows different deployment strategies. How Flagger helps in Progressive Delivery. With the best alerting and notification in place, we are not resilient to downtime due to new releases. How can we be sure of our mission-critical services work as expected? A bad release can cause colossal business value loss. For example, your team might want to test a new feature on a small sample of users, and if that feature performs well, it will be rolled out to all users. In order to do that without causing any hindrance to day-to-day activities. Flagger lets us automate the release process and reduces the risk of introducing a new release in production by gradually shifting traffic to the new release while measuring metrics and running conformance tests. Example of Progressive Delivery with Flagger. Source: stefanprodan/gitops-progressive-delivery Configuration Flagger is compatible with any CI/CD solutions, so it can be used with Flux, Jenkins, Carvel, Argo, etc. It supports various service mesh like App Mesh, Istio, Linkerd, Kuma, Open Service Mesh, or an ingress controller like Contour, Gloo, NGINX, Skipper, and Traefik. It has excellent compatibility with Linkerd and it’s reasonably easy to get started with canary release and metrics analysis. One of the important factors that come into the picture sometime i.e., Flagger doesn’t require replacing Deployment objects with any custom type. Deployment Strategies Flagger implements several deployment strategies which help you achieve the same objective which is shifting traffic gradually to a new version of the release. Some of the strategies are: Canary Releases A/B Testing Blue/Green Mirroring Blue/Green Check out . Flux CD official docs to know more about deployment strategies Metrics Flagger comes with built-in metrics and a Grafana dashboard for canary analysis. It exposes Prometheus metrics to dig more into the canary analysis. You can create custom metrics that can be used to do metrics analysis for release. That’s the beauty of it once Flagger validates service level objects like response time and any other metrics specific to the app, it promotes the release otherwise, it will be automatically rolled back with minimum impact to end-users. We’re not diving into the details of how the metrics template can be used in the analysis step. Manual Gating Not just metrics-based approval, you can perform manual gating to have more control over your canary analysis. There are different kinds of webhooks that you can leverage at each step of canary analysis, for example, confirm-rollout and conform-promotion. A flagger will halt the canary traffic shifting and analysis until the confirm webhook returns HTTP status 200. Flagger also comes with load testing that can generate traffic during analysis. You can read more about . Webhooks - Flagger Let’s look at developer experience for both tools. Developer Experience Flux and Flagger both have a high learning curve and a lot of functionality, which means more power and can sometimes overwhelm the developer. Both don’t have any UI. The setup experience is pretty straightforward. If you talk about logging experience, you might need to get your hands dirty in CLI; otherwise, in other tools, you might have a UI that will show you the current progress of deployment. This makes life easier for a lot of developers. Conclusion We look at both tools and how they fit in our CI/CD pipeline and help us deliver progressively. With the use of Flagger, we can split traffic into proportions, which helps in testing out new releases to a subset of users or even getting feedback. Whether a new release should be released or not to all users. I hope you learned how these tools fit into GitOps with Progressive Delivery practice. References and further reading: Stefan Prodan on Flux, Flagger and the Operator pattern GlooOps: Progressive delivery, the GitOps way GitOps Guide to GitOps

GitOps using Flux and Flagger 

Business success relies on network security. Proper security requires diligence and attention to detail, but some key best practices make it easier. Recent surges in cybercrime and ransomware attacks mean companies must increase their efforts. Here are some tactics that can help companies of any size defend themselves and stay safe amid rising digital threats. Businesses would be wise to invest in them to prevent cyberattacks and keep their sensitive information secure. Why Securing Business Networks Is Crucial Network security has always been a top concern for businesses, but it’s particularly important today. Cybercrime has been on a nonstop upward trend since the onset of the COVID-19 pandemic in 2020. The widespread shift to online operations was a boon for hackers, who took advantage of vulnerable systems that were set up or expanded quickly. Other trends are making the situation worse, particularly ransomware-as-a-service, or RaaS. These are prepackaged ransomware attacks that amateur hackers can buy and deploy with minimal effort. RaaS makes hacking more accessible, so the number of criminals launching attacks on businesses is increasing. Cybersecurity data clearly reflects these trends. For instance, statistics showed a worldwide in 2021. Unfortunately, the ongoing surge perpetuates and worsens things. Experts note that when organizations pay the ransom a hacker demands, it to use that same strategy and target that company again. 105% increase in ransomware attacks encourages other criminals Best Practices for Securing Business Networks What can businesses do about this situation? Ideally, a company’s security infrastructure can keep hackers from getting into their systems at all, preventing the need to either pay a ransom or lose stolen data. These best practices can help organizations get their networks as close to this security level as possible. 1. Block Traffic by Default on the Firewall One of the first steps businesses can take to strengthen their networks is to secure their firewall. A network-level firewall is , often acting as the primary line of defense for a company’s system. Setting up the right firewall rules can make a big difference. responsible for managing traffic One rule businesses should have enabled on their network firewall is blocking all unknown traffic by default. It will automatically prevent unwanted access attempts. Some of these may be legitimate requests from employees, but it is much better to be safe and block everything until it can be verified. 2. Monitor Network Traffic Businesses should also monitor all traffic on their network. There are a couple of reasons for this. It allows companies to identify devices, programs or users unnecessarily using the system. Eliminating these draws on resources can reduce traffic and improve overall performance. Additionally, reducing traffic makes it more obvious when an intruder is using or attempting to access the network. Consistent monitoring allows businesses to quickly identify potential threats and respond to them before it’s too late. 3. Use a Zero Trust Approach The zero-trust cybersecurity framework is gaining popularity today among all kinds of organizations. It prioritizes and maximizing visibility. Businesses that see everything happening in their networks are more likely to notice anything out of place. minimizing attack opportunities Every access attempt and user must pass verification in a zero trust security model. Legitimate users can verify their identities while hackers will be stopped in their tracks. User privileges are minimized to include only what someone absolutely needs and nothing more. This limits the blast radius of any compromised accounts. 4. Use Network Segmentation Network segmentation can be a lifesaver in today’s cyberthreat landscape. This tactic works by into isolated segments. Businesses essentially create “islands” that can’t be accessed between one another. This means that if a hacker does manage to get into one part, the others will be safe since they are isolated. splitting up a network All network segments should be well protected, but segmentation also makes it possible to create different levels of security. For instance, a business could isolate its most valuable data in a particularly well-secured area. Less useful information that needs to be accessed more often could be on a less strictly secured section without endangering anything else. 5. Keep Security Software Updated Antivirus and anti-malware software are the bread and butter of cybersecurity. However, businesses and individuals often make the mistake of downloading and never updating it. One of the easiest steps companies can take to secure their networks is to keep security software updated. Security software developers regularly release updates and patches that include new attacks and threats. Hackers will not hesitate to exploit outdated programs. In fact, some may even develop ways of intentionally thwarting popular offerings. Updating the software ensures it can recognize the most current wave of cyberthreats. It is important to update security software on all fronts. Businesses should make a consistent update schedule for all employees’ devices in addition to the network itself. Individual gadgets are often hackers’ entryways into a network, and vulnerable devices can be used to conduct things like botnet attacks. Therefore, companies should install and update security software on all business-related machines. 6. Test or Audit Network Security Business networks should be professionally audited or undergo thorough security testing. A company could hire who uses their skills to help organizations improve their cyber defenses. They are also known as ethical hackers and look at a network from a criminal’s perspective to find vulnerabilities that might otherwise be overlooked. a white hat hacker White hat hackers will test a business’s network security by attempting a staged attack. They won’t actually harm the system or any data — they will simply try to break into it. Conducting these tests is a great way to see how effective security measures are, identify ways to improve and practice responding to cyberattacks. Keeping Business Networks Safe Securing business networks is a matter of covering and minimizing all potential avenues of attack. Businesses should prioritize increasing the visibility of their systems and reducing access to sensitive data. Mock cyberattacks are a great way to test security measures and practice responding to cyberattacks. Companies can build safe, resilient networks with diligence and attention to detail.

Firewall Configuration: 6 Best Practices to Secure a Business Network

There's still some cases of malware
always-alarmed-and-on, always
large-in-scale in sight and run via
spray pray on-site. Continuing the pernicious part
proactive private network on their
strain-scan; vigilance surges
segment leaders cloud bursting by
scope-scale suspicious scan. A step, one back air-gap gapping
far ahead—
A combination, two-third, learnt
unauthorized; by one time-series
reaching authorized capacity could
or can reinfect reality's ransomware;
the third turned the paired quarantine
containment. As phased past playbook worth noting
as multi-cloud routed to data-driven
multi-layered metadata alongside
enterprise-grade multi-phased
multi-factors. There's still that sector's service as
infrastructure, that third third-category
platform just as. The long-run insight looms large-scale
observability, due deed detecting
deleted defenses; be that brought
burstable necessity to strengthen
internal encryption, be it verified
recovery hunting compromising
investigations. That file-free level of firewalls lain
layer data detecting anomalous
suspicions as vulnerable vulnerability. In that-those reinfected infectious
threat spread across third third-party
volumetric combinations in itself.
That own and only regulated data-trust
responds towards automated
high-fidelity much as may; increasingly
high-confidence as signal technique
ignoring low-latency models. There's still some IP fluctuations,
the reputational and anti-shifting
malware in flight; the tamper-proof
overflow at rest. The intelligent past intrudes clean
copies with little traction on-premise;
a previous key point harnessing
hybrid throughout the web-enabled
threat landscape.
A blast radius permitted by
behavioural-based virtual approach
classifies role-based near-next-generation control. Yet still, there are anomalous endpoints
both-best for compatibility,
the system's operation application
wide-level drill down reports
object-level content-contexts to
comprehensive business-grade
troubleshooting IOCs. Time and again-still, the critical-crucial
data is still secured.

Common Vulnerabilities and Exposures: A Poem 

Imagine you are driving to the store when suddenly your car swerves off the road, completely out of your control. This is what can happen when jackware infects devices. Jackware is a special type of malware made especially for commandeering machines, whether a car, an IoT gadget, an assembly line robot or anything in between. A device that is connected to the internet in any way can be hacked by jackware. Here’s an overview of what it is, signs of an infection and tips for defending against hacks. What Is Jackware? Jackware is a specific form of malware, but it isn’t designed to steal or destroy data. The purpose of jackware is to remotely and hostilely take over “embedded” devices connected to the internet. The most infamous example is the connected smart interfaces in many modern cars. A team of researchers , successfully taking over the brakes while driving at highway speeds. They simply hacked into the vehicle’s entertainment system, using a tactic they suggested would work on virtually any Chrysler car model. tested this tech on a Jeep in 2015 Hackers that successfully develop a jackware program could potentially have a very large blast radius without needing to tweak the program. The Dangers of Jackware The general goal with jackware is to cause destruction, damage or harm by taking over a device against a user’s will. Going well beyond consumer cars, this can have serious real-world dangers. For instance, a hacker could use jackware to take control of connected robots or machinery in a setting like a warehouse or manufacturing facility. This could seriously endanger employees’ safety. Similarly, in medicine, a hacker could use jackware to make a medical imaging or testing device deliver incorrect results, leading to improper care for the patient and potentially threatening their health and safety. This also applies to personal medical devices like pacemakers and insulin pumps. In fact, it is even possible for and other large vehicles. Most heavy transport equipment’s operational technology was simply not designed for cyber resilience, so it can be highly vulnerable to jackware. An attack on something like a public transit train could lead to a major accident, seriously harming those on board. jackware to take over trains How to Detect Jackware on Devices Is there any way for jackware to be detected once it has infected a device? Unfortunately, it’s not easy. Jackware is difficult to find since the infected items often don’t offer users an easy look into system files or code, where signs of malware might be visible. For instance, few people know how to get into the firmware of their car’s entertainment system. However, there are ways to detect malware in general. For example, some tech experts have to secure devices against it. Blockchain creates unique identifiers for data, which can’t be faked or copied. Malware couldn’t hide undercover in a system running on the blockchain. suggested using blockchain technology Additionally, blockchains are great for securely sharing information. The signature of a specific program could be added to a public blockchain people use to detect malware on their devices. Effective anti-malware software may be useful, as well. Jackware is a type of malware, after all. Programs developed for devices like warehouse robots or cars could be run regularly to check for and remove any malicious programs. There are often signs users can look out for without using specific programs indicating the presence of malware. For instance, infected PCs . often run much slower The same could be true for some devices infected with jackware. Maybe a robot gets lost on one of its automated routes, or a car’s interface takes a long time to sync to the driver’s favorite playlist. Any unexplained performance issue could potentially be a sign of jackware. How to Defend Against Jackware All this begs the question: Is there anything users and organizations can do to prevent jackware from getting into their devices to begin with? The short answer is yes. However, much of this will have to happen on the device developer’s end. The problem that cars, trains and medical devices face is a design gap. These machines are often simply not created with cybersecurity at the forefront. Even if they are, they can sometimes take so long to develop that the included security programs are already out of date when they go into use. This is why can still work in some hospitals. The operating systems in these facilities are frequently outdated, making it easy for attackers to score an easy win. malware over a decade old Perhaps the first step toward preventing jackware infections is to keep operating systems and cybersecurity measures like antivirus software up to date. An effective anti-malware program can go a long way. Device developers need to start building them into their devices, though. As of 2022, there are no after-market options for antivirus software for devices like cars. The items targeted by jackware are often isolated, making them essentially defenseless. Even if a user knows their gadget may be at risk, there aren’t any extra defenses they can add to it. It falls on developers to take jackware seriously and prioritize it in the design and operating systems of vulnerable vehicles, medical equipment and IoT devices. There are still some to keep their devices safe, though. For instance, network segmentation is a great way to minimize how much connected devices are exposed to the wider internet. For example, everyday browsing on phones and laptops should happen on a separate network from the one that operates a warehouse’s IoT robots. steps users can take Strong passwords on all devices, networks and accounts are also a must. Even if jackware gets into something, strong authentication measures will help prevent it from successfully taking control. Protecting Devices From Jackware Jackware can be an especially dangerous form of malware. It is difficult to detect and defend against. Developers need to take concrete steps to prioritize modern cybersecurity measures for items at a high risk of attempted attacks. Dedicated anti-malware software designed for these unique devices and modern operating systems to support them could help protect them from jackware. Users can also implement network segmentation and strong authentication measures on all their devices and accounts.

Jackware: Malware That Controls Machines

is a shooter looter game with Play-to-Earn (P2E) elements that is being developed on the Polygon blockchain. Players may win rewards in the form of NFTs as well as the game's native currency, XPND. Time Raiders The game is currently in the Beta testing phase and revolves around a time-traveling shoot and loot style gameplay where in-game assets are dropped as loot. Let's take a closer look at its gameplay elements and the NFTs within its ecosystem. Overview & Gameplay Time Raiders is set in the future and players will be able to travel across different settings in time to access various levels, including Medieval Europe (Knights and Lords), Edo Period Japan (Samurai), and even the Prehistoric Era (Dinosaurs). However, the original main setting of the game will take place in World War II Era Europe, with the player facing off against the Nazis. Initially, players will start off with a basic character that is fully customizable and upgradeable. Players can also recruit companions of different classes, each one with class-specific weapons, items, and abilities. These classes are Commando, Sniper, Heavy, Spy, Engineer, Chemist and Assassin. The player character and their companions can be upgraded and customized with new gear, weapons, and items. Certain companions also give the player access to certain regions, which could encourage players to explore every character and companion class in order to experience the game in its entirety. Similar to strategy games like Divinity Original Sin and Dragon Age: Inquisition, some levels will require a specific combination of character classes to discover rare and unique items. The combat mechanics of the game revolve around a run-and-gun style where players shoot up waves of different enemies who drop loot that can be sold, traded, and used in-game. Bosses drop the most valuable loot as well as give the player a chance to earn a production facility that generates in-game assets for the player to use in their missions. Facilities include mines, munitions factories, labs, and production facilities which need to be built and maintained using in-game staff. Players can stake Xpendium and their NFTs in the facilities and unique resources will be produced based on the facility's specialty. In-Game NFT Assets In-game assets exist as Non-Fungible Tokens (NFTs) that can be earned, traded, sold, or staked for Xpendium, the game's utility token. Despite this, players don't need to purchase an NFT to get started, instead, they start off with a basic character that they can use to earn in-game items, all of which are NFTs. These NFT assets come in different rarities and include consumables, vehicles, and weapons. Initial in-game items include WW2 Era planes, tanks, boats, and weapons as well as prehistoric animals, dinosaur eggs, and special characters. Time Raiders is having an NFT Pre-Sale that will be going live on on Wednesday 20th July at 12pm UTC. Participating platforms include BitMart NFT, Gate.io, Babylons, Enjinstarter and Rarible. The Pre-Sale NFTs are listed below: Churchill Stamp This is a founder's token with a total supply of 999 that provides players with perks that include regular NFT rewards, 250 upgrade energy, and 250 extra level energy as well as a chance for better loot drops from enemies. This token also grants users access to both the Helen 2237AD gear and Jason 2237AD gear NFTs. 250 founder tokens will be sold for $1000 each. U-Boot These U-Boots will be used by players to clear large groups of players by directing missile strikes. It will also be used to travel to Nazi strongholds in base raids. 350 of the 500 U-Boots will be sold for $300 each. Lancaster Bomber These bombers can be used by players to direct airstrikes to take down multiple enemies. In future updates these aircraft will be used to transport enemies to island strongholds, allowing players to destroy dams and buildings. 350 of the 500 Lancaster Bombers will be sold for $300 each. Lancaster Dambuster This aircraft can be used by players to launch airstrikes and bouncing bombs on enemies, destroying personnel and buildings that are in the blast radius. The aircraft will be used for attacking island bases in future updates, as well as unlocking special levels by destroying certain structures. 250 of the 500 Lancaster Dambusters will be sold for $400 each. Spitfire Spitfires can be used to launch a barrage of gunfire on enemies as well as be used in Nazi bases raids. 350 of the 500 Spitfires will be sold for $300 each. VI Rocket These rockets can be used to clear large groups of enemies, vehicles, and buildings. It will also be useful in destroying architecture such as dams during base raids. 400 of the 500 VI Rockets will be sold for $250 each. Victorian Hot Air Balloon Players can use these balloons to reach higher levels of elevation, to reach hidden treasures on certain levels. Wounded players, loot, and equipment can also be airlifted back to the Hub. They can also be used in Victorian and Steampunk Era levels by players. 400 of the 500 Victorian Hot Air Balloons will be sold for $250 each. Pterodactyl These dinosaurs can be summoned through time portals to help players take out enemies, drop health packs and drop multiple items in their own time era. In future updates, this NFT will give players access to special game modes in the prehistoric era. 400 of the 500 Pterodactyls will be sold for $250 each. Triceratops These dinosaurs can be summoned through time portals to charge enemies in a straight line. It can also be used as a battering ram to knock down obstacles and in future updates, this NFT will give players access to special game modes in the prehistoric era. 400 of the 500 Triceratops will be sold for $250 each. Hover Bike Hoverboards can be used as transport on levels and as a way o transport characters between different eras. It also functions as a mini-tank that can mow down enemies. In future updates, this NFT will give players access to special game modes in futuristic levels. 400 of the 500 Hover Bikes will be sold for $250 each. Tiger Tank Tanks can be used to take down enemies and enemy structures and other tanks. In WW2 levels, Tank owners will get access to special game modes. 250 of the 500 Tanks will be sold for $500 each. There are also a special Winter Assault and Desert version which are more rare. Helen 2237AD gear A limited edition gear set that provides extra buffs to a player's stats, defense, and critical hit capabilities. 500 of the 1500 Helen 2237 AD gears will be sold for $250 each. Jason 2237AD gear Similar to the Helen set, this is a limited edition gear set that provides extra buffs to a player's stats, defense, and critical hit capabilities. 500 of the 1500 Jason 2237 AD gears will be sold for $250 each. Gen 1 Neos-Mech gear This is a special Gen 1 Gear that will add extra buffs to the player character and turn any of your Raiders into a “Heavy” Class. This NFT also increases armor and attack capabilities whilst providing short periods of invincibility and heavy burst fire. 500 of the 1000 Gen 1 Neo-Mech gears will be sold for $250 each. Dinosaur Eggs Dinosaur Eggs can be nurtured for 6 months to hatch a Pterodactyl, Triceratops, or even a baby T-Rex NFT, which upon hatching have unique stats and a special ability. This NFT also unlocks secret levels in future updates. 500 of the 750 Dinosaur Eggs will be sold for $500 each. Treasure Map Series P This is a treasure map NFT with a total supply of 200 that will be used in future releases to send a signal to players when they come close to treasure on certain levels. It will also serve as a way to eventually find the hidden “Ark of the Covenant”, which holds 1,000,000 waiting for the lucky player who finds it. 100 treasure map NFTs will be sold for $750 each. In Closing Time Raiders is a shooter looter game that includes Play-to-Earn. In-game items that exist as NFTs and give players access to additional levels and actions. The NFT pre-sale will go live on the Wednesday 20th of July via BitMart NFT, Gate.io, Babylons, Enjinstarter and Rarible and you can join the whitelist . here

Let’s Look at Time Raiders: An NFT Treasure Hunting Game

A few months ago I had an opportunity to give a presentation to soon-to-be Computer Science (CS) graduates. We presented the software development process ( ), and how different teams at Schweitzer Engineering Laboratories adapt the development process to their needs. We ended the presentation with tips for what to expect entering the industry. SDLC from There is a big disconnect between what we learn while getting a CS degree and writing software that makes money. Not to say a CS degree isn't worth it; quite the opposite. I still use the algorithms, graph theory, data structures, and development processes taught in college. But, there is so much more to software engineering than code and theory. In this article we'll walk through the tips I would give myself leaving college, and the tips I gave to those soon-to-be CS graduates. Don't worry about knowing everything I've been programming a long time--I'm websites old. I've contributed to many coding communities, built and maintained high-traffic applications with near-zero downtime, gave conference talks, released a course, and written a lot of these silly articles. If you were to pull me out of a crowd and ask me to invert a binary tree I would probably struggle. I've been rejected from many job interviews and called "not senior enough". 1996 Space Jam The point is we all face rejection no matter how much we know, or how much experience we have. We can always be better. Don't fret about not knowing everything, and don't be afraid to say, "I don't know", but always follow up with, "But I'll find out". Throughout my four years getting a Computer Science degree I thought if I knew all the algorithms, and produced the fastest code I would be the best programmer. These things help, but after my first experience as a professional software engineer, I quickly learned there is so much more to software than Big O notation. It's not about knowing everything; it's being curious and able to figure it out. Ask questions, have opinions This piece of advice piggybacks "Don't worry about knowing everything", and adds some spice. Don't be afraid to ask questions. Ask the senior developer why they came to a certain solution, or how is different than in JavaScript. This is a two-way street. When you become a senior software engineer ask the junior engineers questions. Map() {} Remember, we can't know everything, but speak up when we do know something! Have opinions. Yeah, not every opinion will be correct, but this is how we learn. As a manager, I like when interns have opinions on architecture. This shows they care, they're engaged, and they're learning. Just don't be a jerk about it. Ask questions on the things you don't know, and have opinions on the things you do know! Have a business-oriented mindset We leave college with the wrong mindset of what companies look for. I thought software companies wanted the best software engineers because it makes them the best. Don't get me wrong, there is value in being good at writing software. Let's say we write a highly decoupled, blazing-fast, platform-agnostic, cleanest code application. If no one uses the application then all we did was create a waste of time and money pit. Great software engineers consider both technical business needs. We need to think about how our decisions produce value. Switching frameworks may sound cool, but who gets the value out of that? If the old framework isn't maintained anymore, and we need to change to get security patch support then maybe it's worth switching frameworks. If we want to change frameworks, because we saw a post on about it then maybe reconsider. and Hacker News When I get asked how to get promoted and move up the software engineering ladder this is the biggest advice I can give. Consider how your skills produce value for your company. Same for writing a resume or interviewing. It's cool you know , but how does that transfer to producing value at the company you're being hired for? Maybe since you had to learn Haskell for a class you are a quick learner, and can onboard quickly? Haskell Technology is a . Our applications solve problems users have is the goal. means to an end Everyone breaks production You're going to break production. Everyone does it. Even that lead engineer you look up to who never does wrong has broke production at some point. Don't stress you're going to break production. A colleague, who did the talk with CS graduates with me, has a saying, "Optimize for mean to recovery." Find ways to reduce the blast radius once production is broken instead of worrying about breaking production in the first place. This could be: if Breathe in. Breathe out. Let it go. Having you can rely on when . Find a support system who can jump in and help when production breaks battle buddies sh*t hits the fan Learn everything about the environment. Ask questions not just about the systems you work on, but neighboring systems. How does each piece connect? Improve your skills and learn different parts of the software stack. Learn how Databases work, maybe learn networking and DNS, and if you're working in containers maybe introduce yourself to Kubernetes When interviewing for a company look for blameless cultures. This means when something eventually breaks in production the team doesn't start pointing fingers. Ask the interviewers how they deal with outages, and watch out for warning signs. Many buzzwords without any concrete plan/action can be a cause for concern. Lastly, writing software is a team effort. When software breaks there are multiple chains in the process of breaking down. Maybe code reviews weren't as thorough as they could have been? Or maybe we're missing testing or test cases that would have caught the error? Did the step run? Maybe the architecture is inherently complex? As engineers, we like to point to a root cause ( ), but the didn't sink for one reason. The builders of the ship cut costs, the ship was moving too fast, and the ship's radio operator dismissed the warning (Pruitt, 2018). Find a team with a blameless culture and don't point fingers when systems fail. Iterate on failures to learn and get better. Software is a team pursuit. Continuous Integration Fallacy of the single cause Titanic Also Published Here References Pruitt, S., 2018. . [online] History. Available at: [Accessed 4 July 2022]. Why Did the Titanic Sink? https://www.history.com/news/why-did-the-titanic-sink

Tips New Software Engineers Should Know

We’re excited to announce the availability of a new, first-of-its-kind Features Dashboard in Bugsnag. It has been created to provide development teams the observability and actionable insights they need to make data-driven decisions about new feature rollouts and gain confidence in accelerating releases. Progressive Delivery, Feature Flags, and Experiments Today, development teams are under increasing pressure to ship new features faster to boost user engagement, retention, and grow competitive advantage. In our recent , we analyzed release frequencies across 10 major verticals and confirmed that weekly releases are the new norm. Application Stability Index Large and infrequent releases have been replaced by smaller and more frequent releases as teams adopt to build, test, and deploy code. progessive delivery Teams doing progressive delivery use , like issues slipping into production and impacting the quality of the application and the user experience. feature flags to ship code faster and minimize risks Feature flags are a way to manage these risks because they allow teams to deploy when they want, to whom they want, and dynamically adjust in production based on the impact on the user experience. Experiments or A/B tests are an extension of feature flags where one or more variants are compared to a control group. When the experiment is complete, the most effective variant that meets stability goals is rolled out to all users. New Features Dashboard Previously, Bugsnag users could segment errors occurring in feature flags and experiments using custom filters for arrays. With the new Features Dashboard, you can proactively monitor errors in feature flags and experiments. The new feature details page shows errors that occurred when the feature flag or experiment was active. Seen errors are all errors that occurred while a feature flag was active and exclusive errors are errors that only occurred when the feature flag was active and did not occur when it was not active. Exclusive errors should be investigated to determine if they have been introduced by the feature flag or experiment. If investigating a spike in errors, you can filter the existing Inbox and Timeline views to identify what features or experiments were turned on and may have been linked to the increase in errors. Additionally, reproducing and fixing any error in the application is more efficient because you can see what features or experiment variants were active at the time of the error. Let’s dive deeper into the observability and insights delivered by the new dashboard. Real-Time Observability For Features and Experiments The new dashboard provides you the proactive monitoring needed to understand how feature flags and experiments are impacting the user experience. As feature flags and experiments are rolled out, you can gain real-time insights into errors in the application. Similar to how can be set up for saved error segments in Bugsnag, alerts can be configured for feature flags so that the team responsible for developing and rolling out a particular feature can be alerted of errors impacting the experience of users who have access to that feature. alerting In addition to being able to zoom in on the errors occurring in feature flags, you can also determine if unusual error activity in the application is connected to a feature flag. In the Timeline view, pivot tables for feature flags can be used to isolate errors that occurred when the feature flag was enabled. Make Data-Driven Decisions About Feature Rollouts Teams using progressive delivery phase the rollout of features to their users to get their code in front of early adopters and limit the blast radius of any issues that may come up. Phased rollouts are basically when you progressively increase the number of users that are able to see and are impacted by the new feature or experiment. Now, with the actionable insights in the Features Dashboard, you can make data-driven decisions about feature rollouts. Monitor the impact of features and experiments on application quality and user experience to inform decisions about continuing the phased rollout and releasing a feature to more users if there aren’t too many errors or rolling back if there are issues that need to be addressed first. If running an experiment, you can see the errors in each variant and decide which one meets your quality standard to be released to production. Gain Confidence in Accelerating New Feature Releases We mentioned that development teams are under increasing pressure to ship new features faster to boost user engagement, retention, and grow competitive advantage. However, moving faster comes with risks, like more errors being introduced into production and decreasing the . quality of the user experience The new Features Dashboard helps you speed the pace of delivery while minimizing these risks. With proactive monitoring for feature flags and experiments, you can discover and fix issues with new features when they are exposed to a smaller subset of users and then re-release a more stable version into production. You can gain confidence in releasing to production knowing that the feature will not degrade the quality of the user experience. Start Using the Features Dashboard Today The Features Dashboard is currently available for , including Android, iOS, React Native, Unity, Unreal Engine, Expo, JavaScript (browser and Node.js), and Electron. Additional platforms will be supported soon. client-side applications If you're a current Bugsnag user, start monitoring features and experiments in the new Features Dashboard today by configuring the Bugsnag library in your application. Learn more by reading which includes . our documentation, guides for each platform If you’re new to Bugsnag, start a or to see the capabilities of our in action. 14 day free trial request a demo stability management platform Bugsnag helps you prioritize and fix software bugs while improving your application stability.

Progressive Delivery, Feature Flags, and Experiments: The Story of a New Dashboard

The concept of microservices, an approach to designing a software application as a set of small services, has been around since at least 2015. Delivering benefits such as the independent deployability and scalability of components, microservices are all the rage today. This is because these microservices benefits translate into incredibly faster software development speeds. With consumers being quick to change their preferences and behaviors, microservices adopters are able to keep up. Life is now great, they say. As much as 56% of companies participating in a plan to adopt a microservices approach in the next 24 months. Almost 80% of current users say their business will likely step up investment in microservices. Microservices advantages have prompted Netflix, Amazon, eBay, Twitter, and many other tech giants to migrate from monolithic to microservices architecture. But should your company use microservices? It depends on the context and if microservices pros outweigh the cons for your application. This blog provides an overview of a microservices vs. monolithic approach and five key benefits of using a microservices architecture. It also shares some of ITRex’s microservices experience and offers tips on when business should (not) use microservices. Dive in. recent IMB survey Microservices definition and comparison with monolithic architecture A microservices style is an approach to as a suite of small components, or services, which are designed around a single business workflow and work together. Essentially, microservices are part of a , a culture in which development and IT operations teams cooperate closely together using automation tools to deliver faster. Microservices: What is a microservices architecture? developing cloud-native software applications fundamental shift to DevOps Are autonomously developed Use their own database and may be written in different languages Communicate via APIs with lightweight protocols like HTTP, message brokers, or event streaming Perform a specific business functionality For instance, a microservices-based e-commerce application might have independent services responsible for product images, user profile management, search, inventory verification, payment processing, and shipping. The front end (the customer-facing side of the website) is decoupled from the back end (the business-facing side) so that it’s possible to customize and manage them separately. If you take an example of Amazon, a microservices architecture might look overwhelming, if not terrifying. Amazon Deathstar. Source However, without using a microservices architecture, Amazon would have hardly evolved into one of the most valuable companies in the world (valued by a market cap of $1.694 trillion as of December 2021). The decision to leverage the benefits of microservices was made back in the early 2000s when Amazon understood that it was failing to scale at the speed of customer base growth because of slow development and coding issues. Netflix woke up to the benefits of a cloud-based microservices architecture in the late 2000s after it was unable to mail DVDs to customers for a few days due to a massive database corruption. After breaking their application into over 700 microservices, Netflix engineers are able today to deploy code thousands of times per day, allowing the company to stream around 250 million hours of content daily to more than 200 million members worldwide. What architecture did these tech stars and many other companies use previously, in pre-cloud days? They used monoliths. A monolithic application is built as a single unit that combines all components, including a client-side user interface, server-side operations, and a database. Typically, a monolithic architecture: What is a monolithic architecture? Has a single codebase for all functionality Is tightly coupled Uses centralized data An e-commerce application developed using a monolithic approach would consist of tightly coupled front-end and back-end services deployed as one unit, meaning that any customizations would need changes in the codebase and the front-end platform (see the diagram below for comparison). Monolithic applications are far from dead. Actually, they still can be a good choice because they are often easier and cheaper to build (at least in their early days). However, they come with drawbacks. A change in one part, whether for upgrading or scaling purposes, often requires rebuilding and redeploying the entire system. Likewise, the entire system can be brought down by one misbehaving part, meaning monoliths are fragile. Monoliths are also difficult to maintain as they grow, and integration with third-party tools is no joy either. These drawbacks are hard to ignore in today’s disruptive market environment in which businesses should react rapidly to changes to survive and thrive. Hence the buzz about the benefits of microservices that are built by . DevOps teams 5 key benefits of microservices This is perhaps the most important advantage of microservices, at least according to Sam Newman, one of the early pioneers of microservices. Making changes to an application to improve performance or add a new feature in response to emerging user needs is a breeze with self-contained microservices. Each service can be modified and upgraded without touching the entire system. They can be scaled independently from one another as well if one feature is under too much load because of excess requests. For instance, you can scale only your payment processing service if you are receiving more payments, without ramping up resource consumption by other services. This way the process requires less infrastructure and leads to cost savings. 1. Independent deployment The loose coupling of a microservices architecture also provides another advantage of microservices — better resilience. Clear boundaries between the services, coupled with their micro size, limit the impact of new releases and ensure fault isolation. A failure in one service does not take down unrelated functionality, with the rest of the system remaining intact and continuing to provide services to users. 2. Lower blast radius of failure This is a third benefit that microservices deliver if done correctly. Data sovereignty per component is an essential feature of microservices. A microservices architecture makes it possible to clearly delineate services that touch data, which is critical, especially if the organization needs to comply with healthcare data regulations or the GDPR. 3. Data isolation As monolithic applications have a single codebase, it is difficult to customize a tech approach for each functionality and a compromise is often sought. Microservices, in contrast, are designed around business capabilities by default, allowing teams to choose the best available technology for a particular functionality to make the most of it. This is because microservices can use different technologies or programming languages for different components. Microservices also simplify adopting the latest technology or integrating with third-party tools as needed. The absence of vendor lock-in is another microservices advantage naturally stemming from its loosely coupled architecture. 4. Use of the right technology The microservices approach enables companies to set up small, cross-functional teams around one service or a suite of services which can operate in an fashion. This model minimizes handoffs when one team needs to wait for another to complete their task, be it deployment or testing, before they can start their work. With no dependence on another team, the speed of development accelerates. 5. Efficiency agile Adopters are reporting multiple benefits of using microservices, according to the IMB survey of 1,200 IT executives and developers. The most important microservices advantages they’ve felt include: 30% - Higher customer satisfaction 29% - Better security of company/customer data 29% - Faster time to market 28% - Improved application performance 27% - Greater flexibility to scale resources up or down 26% - Improved employee productivity Are there any challenges with microservices? Well, as a popular quote goes, microservices are not a free lunch. Read on. The bad part about microservices The inherent complexity of microservices increases with the number of services. This complexity is multifold and attributed to the following: 1. Complexity Top-down control at technological and operational levels is impossible Testing is hard, and there will never be too much test automation Implementing inter-communications is tricky so talented developers are needed The amount of data logged is too big, which may lead to its inconsistency Compatibility issues may arise with new versions There are difficulties with provisioning the right amount of resources Microservices give companies more options to earn money but not save it. Apart from the cost of hiring developers capable of building a complex microservices environment, there are cloud and APIs bills. The good news is, ongoing costs can be significantly optimized as microservices use on-demand resources on a pay-as-you-go basis. 2. Costs Half of the respondents in the IBM survey cited security among the top challenges that they faced on their microservices adoption journey. Security needs to be baked in from the beginning as each microservice has its own set of entry points to communicate with others via various infrastructure levels, leading to increased application exposure to attacks. Besides, scaling infrastructure amplifies the risk of losing control and visibility of application components. 3. Security risks When (not) to use microservices And finally, our last question: when microservices architecture is worth the hassle? While the buzz behind microservices as a natural fit for cloud-native applications is all warranted, they shouldn’t be your default style. The literature puts it simply: start with a monolith and split it up when you run into scalability or resource consumption issues, or anything else that justifies taking the microservices path. Here are our key tips when NOT to use microservices: It will be wiser to start with a monolithic application and break it into smaller components when it becomes too tricky for a two-pizza team. What you want is to run cheap experiments rather than investing loads of time, effort, and money into building out a complex architecture for a product whose customer value is yet to be validated. Monoliths are a perfect way to test out (and discard) MVPs to learn fast what will bring value to your customers. As Martin Fowler, another well-respected microservices guru, says: i) Almost all the successful microservice stories have started with a monolith that got too big and was broken up. ii) Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. 1. If you are a startup, microservices are a bad idea. Note: If the product domain is uncertain, you shouldn’t use microservices either when you are getting started. It might be just too early to leap into complex architectural decisions, and chances are your approach to setting up communications and boundaries will be way off the mark when your project matures. Rolling out a complex microservices architecture for your company’s event scheduling tool might indeed amuse your developers, but will it be worth all the trouble? Microservices are in the first place designed to address one problem: complexity. As Martin Fowler states, "don't even consider microservices unless you have a system that's too complex to manage as a monolith." 2. Microservices are not a great choice for a solution that is not complex and can be maintained by a relatively small team. Do your inventory management or purchasing systems need to be converted to microservices if they are doing perfectly well what they should as they are? Once again, the idea of using microservices is to break a complex application into a set of smaller services. Decomposing a code that is already small and straightforward would only have the effect of adding complexity — now you have to navigate all deployment, interoperability, and debugging issues with a multitude of artifacts instead of deploying the entire unit in a good old-fashioned way. 3. Don’t go for microservices if your application is too small to justify them. OK then, but when to use microservices to reap their benefits? Microservices make sense when any of the statements above is false. In other words: When your product evolves into something complex that needs to be tamed or when you want to keep up with changes and add important features that are otherwise impossible to implement because of monolithic architecture bottlenecks. When you are building a big and complex product with a defined scope from scratch. Whenever a company wants to organize dozens of developers to build a large-scale solution with a clear set of features, it should consider setting up small, cross-functional teams, each responsible for a single component. This way every team can work independently, with dedicated persons handling API management, data pipelines, schemas, and other capabilities. A fair, real-life example from the ITRex portfolio would be an in-house cybersecurity tool that the client wanted to convert into a . Microservices was a natural fit for this project because a monolithic architecture just can’t provide the scalability a SaaS solution needs to serve the growing number of customers, or flexibility to evolve and stay ahead of hackers. Another illustrative project was an for a global retailer. Our client wanted a cloud-agnostic solution built from the ground up. It was clear from the beginning that the platform would handle tons of data and should be designed as scalable to cater for new data sources to be added in the future. We also had to factor in the need to build communications with multiple external services. So realizing the benefits of microservices in this project was a natural strategy as well. The microservices architecture enabled us to smoothly roll out this complex system, using for orchestrating microservices and APIs. And there was an equipped with 3D cameras and an ML model which came with IoT sensors attached to the user’s equipment. Its major components, including an admin panel, an Android app, and a rules management system, had been built by different teams at different stages of the project, each using a different code and architecture. When the complexity of handling them all became overwhelming, we understood that we needed to build one backend for centralized management. And we converted them into microservices, redesigning their code and creating new databases. There were other benefits of using a microservices approach, like avoiding duplicate code or functionalities. So, in our experience, it is preferable to use microservices when you need to manage growing data volumes, handle interoperation complexities, or ensure that your system is flexible enough to evolve with the business. Security-as-a-Service platform AI-powered big data platform Kubernetes AI-powered fitness mirror Endnote The microservices revolution is unfolding as companies are realizing microservices advantages to get an edge in the market. The benefits of microservices allow organizations to be nimble and agile amid disruption that has become the new normal. Being able to deploy better software, faster makes them ready for anything that comes next after “what’s next.” Before following suit, it’s just important that you know what microservices benefits can be available to your company and whether the hassle will be justified. Other than that, microservices can do wonders. Still confused if your company should fall for the benefits of microservices? with ITRex consultants. We will help you figure it out. Get in touch

Microservices vs. Monolithic Architecture

The last decade has seen information technology enjoy a breathtaking period of innovation. As a result of this ongoing evolution, our industry has developed a complicated relationship with obsolescence. Often we keep old tech around, even after a much-improved alternative becomes available. However, this legacy technology can add complexity and slow down innovation and has a negative impact on operational costs and information security. Tech Layers Keep Growing Today, we run virtual machines (VMs) on top of bare metal Linux, with containers inside, managed by Kubernetes which - despite often being described as an “operating system for data centers” did not replace Linux, an operating system that was born in simpler times. In fact, the number of technology layers that our applications depend on just keeps growing. Sometimes there is a valid reason to keep the old stuff around. Containers don’t provide secure process isolation like VMs do, for example. But we don’t pay enough attention to getting rid of the tech that is obsolete and that creates complexity and security gaps. Complexity creates security liabilities Complex systems are harder to secure than simple ones. For the most part, human error is the foundation of every successful hacking attempt. And the probability of a human error grows higher as complexity in the tech stacks increases. To put it simply, every existing technology in your computing environment: Listens on a network socket Requires encryption Offers authentication and authorization Comes with its own audit capabilities Has its own list of dependencies, each with several configuration files with varying syntax In almost every use case, configuring all of these components properly is crucial to infrastructure security and for meeting compliance requirements. As engineering teams and computing infrastructure grow over time, properly configuring every computing resource and maintaining secure configurations have proven to be an insurmountable task for most DevOps teams. But it’s not just the teams that grow. The surface area needing protection continues to increase as well. The same valuable data can be stolen via multiple attack vectors, including but not limited to: Exploiting a bug in a developer’s code Software supply chain attack SSH or RDP Virtualization APIs such as EC2 or its private cloud equivalent Kubernetes API Database’s own remote management interface Database management or CI/CD web UI Network access such as VPN The difficulty of managing secure infrastructure access across all of these “access doors” is compounded by the fragmentation of the information security industry. Different vendors offer point solutions for network perimeter security, operating systems, databases, software supply chain, and so on. This leads to “infrastructure access silos.” Consolidating access As recently as 10 years ago, servers weren’t as numerous. Each piece of middleware installed on a server had its own remote access interface. Fast forward to today’s cloud-native reality and servers come and go by the thousands. For that reason alone, the number of remote access interfaces that exist at any given time is hard to keep track of. The obvious answer is to consolidate all access into a single, easy to manage component. In other words, an organization should consider having a single source of truth for remotely accessing everything, one which consolidates the following elements: Encrypted connectivity to all computing resources Authentication Authorization (policy enforcement) Audit If we could consolidate all four pillars of remote access with a single simple solution, that would finally create a single “door” for accessing all components of computing infrastructure. Can we securely consolidate all access? With a not-so-secret ingredient called “identity,” the answer is a resounding yes. The role of identity For this consolidation to work, every DevOps engineer, every software developer, every server, database, microservice must be issued an identity by the same authority which also stores access policy and maintains a unified audit log. Having a single source of truth for the identities of everyone and everything allows stakeholders to consolidate authentication, authorization and audit. In turn, this dramatically simplifies the configuration burden and reduces the attack surface area to the bare minimum. When each access event is processed according to the identities of hardware, software and a human involved, it allows security-focused teams to implement a highly granular policy with minimal required privileges. This dramatically reduces the blast radius from a compromised account. Consolidation through Certificates The prime technology candidate to consolidate identity-based access is certificates issued by a central certificate authority (CA) that are portable, remove the need for passwords, contain arbitrary metadata about their owner and have an expiration date. Historically, there were several primary factors that hindered the widespread adoption of certificates: Lack of a single source of truth for the identities of all engineers. Legacy workloads did not support certificates natively. Configuration complexity of certificates vs simpler static credentials. When combined with identity-aware reverse proxies, certificates can be used for accessing legacy resources that do not support certificates natively. The key aspect is to both connect to an identity platform and find a way to issue certificates which can be later used to establish connections to legacy resources that only listen on a localhost socket. By only supporting certificates and nothing else, an identity management platform eliminates the complexity that has historically been associated with using certificates in practice. This level of simplification of access, and reduction of components involved, is a welcome development. More importantly, it provides a single source of truth across all existing tech stacks, treating the ones that should have been made obsolete in the same manner as the next-generation compute systems that developers and engineers need to do their job.

Stories, News & Mentions about BLASTRADIUS

Blastradius’s Stories on HackerNoon