There is opportunity for the appropriate level of regulation to give DeFi enough breathing space to make a difference: boosting transparency, increasing financial inclusion and enabling credit to 8 billion people that will see the world take a tremendous jump toward prosperity. Yet there is also potential for overreach that would stifle innovation and growth and have unintended consequences. Unfortunately, we seem to be well down this path already. What is needed is the realization that DeFi shares many of the same goals as financial regulators: overhauling inflexible processes and delivering wider access, cheaper prices and more stability — all while ensuring these benefits are widely shared with all participants in the market. ... DeFi has the potential to create fairer, more transparent and more liquid markets through completely new mechanisms, helping everyone to reduce fraud and front-running, resolving fragmentation and creating markets that are efficient, resilient, fair and equally accessible to all — not just participants that have the right connections.
The most striking difference between what we do and what software developers do is in our end products. In software, the goal is to get to a product that the end-user loves. In data, our goal is to help people make a decision they trust, and the journey the user takes to get there can be just as important as the end result. Most commonly we see this manifested in how we tell stories with our data. We use notebooks to capture context and process, and presentations to guide users to an understanding. It’s in this process that we establish trust, turn charts into insights, and make our data valuable. This is also the driver behind one of the greatest pains of our work: the follow-up questions, and ad-hoc requests. These questions and requests come from a place of curiosity and represent a desire to have that same intimate understanding of data that we get in crafted data stories. And yet, in practice, we try to eliminate these questions with processes that front-load requirements gathering and tools that have made no room for this way of working.
Deployable in minutes, Cloudentity empowers businesses to deliver Open Banking, Embedded Finance and other innovative online services without changing identity providers or application code. Cloudentity delivers a declarative identity and authorization framework that works across any cloud to simplify access control and data governance. From Open Banking to eCommerce fraud prevention, Cloudentity makes it easier to deliver cloud-native applications and safer to extend your data to the customers and partners that matter most. A standout capability of the new SaaS platform is its drag and drop Data Lineage feature, which provides a simple and intuitive way of mapping identity and user context data to an application. For developers, Data Lineage solves the complexities of Single Sign On (SSO) and provides real-time control over who can access each element of your API data. For ITops, DevOps and SecurityOps, teams can rapidly validate controls and pinpoint areas that need to be updated or fixed to prevent API data leakage and meet personal data protection obligations.
Humans and technology have always had co-dependent challenges. Let’s face it, it’s one of the main reasons my career exists! So it stands to reason that human inference, whether deliberate or not, is a common reason for losing information. This can be as innocuous as uploading a CSV file that corrupts data sets, accidentally deleting product listings, or overwriting code repositories with a forced push. There’s also intentional human interference. This means someone who has authorized access, nuking a bunch of stuff. It may sound far-fetched but we have seen terminated employees or third-party contractors cause major issues. It’s not very common, but it happens. Cyberthreats are next on the list, which are all issues that most technical operations teams are used to. Most of my peers are aware that the level of attacks increased during the global pandemic, but the rate of attacks had already been increasing prior to COVID-19. Ransomware, phishing, DDoS, and more are all being used to target and disrupt business operations. If this happens, data can be compromised or completely wiped out.
Why shouldn't you be too concerned about your uptime metrics? In reality SRE can mean different things to different teams but at its core, it’s about making sure your service is reliable. After all, it’s right there in the name. Because of this many people assume that uptime is the most valuable metric for SRE teams. That is flawed logic. For instance, an app can be “up” but if it’s incredibly slow or its users don’t find it to be practically useful, then the app might as well be down. Simply keeping the lights on isn’t good enough and uptime alone doesn’t take into account things like degradation or if your site’s pages aren’t loading. It may sound counterintuitive, but SRE teams are in the customer service business. Customer happiness is the most important metric to pay attention to. If your service is running well and your customers are happy, then your SRE team is doing a good job. If your service is up and your customers aren’t happy, then your SRE team needs to reevaluate. A more holistic approach is to view your service in terms of health.
Another key element is creating the right culture and environment for diversity to thrive. In a gender context, an important aspect here is male allyship. Men have a real role to play in supporting the ‘levelling up’ agenda. They need to see that increasing gender diversity and equity is not just an issue for women themselves – it’s for everyone. They can become active allies through their own behaviours and actions. This extends right up to board level and executive leadership. We need to continue to work to influence leader behaviour and build their understanding of people’s different styles. Instances of men talking over women in the boardroom or not listening to ideas are still all too common. Reporting is also critical. You can’t change what you don’t measure. Collating diversity statistics and reporting them to the board and more widely around the business is an essential part of raising awareness and stimulating action. Transparent reporting was in fact seen as the most effective lever for improving diversity and inclusion in this year’s survey.
When employees feel their personal ambitions are too difficult to achieve, they start to think about leaving. Those ambitions might involve having a family while maintaining a career, gaining a range of professional experiences, or even accumulating personal experiences such as travel. People will ask: “I don’t mind making sacrifices, but are the trade-offs producing the benefits I expected?” When that question surfaces, employees are already halfway out the door. For example, young men and women who are working extremely hard and don’t have time for friends, exercise, or adventures may start to doubt that the company is the right place for them—even if the pay is fabulous. ... Managers often show great care about performance and little concern about the whole person who is delivering the results. Feeling uncared for is deadly for motivation and destructive to performance over the long run. Many managers rarely ask about other aspects of their team members’ lives, their personal interests, or their ambitions. Too few managers show genuine understanding and appreciation for what it took to deliver such great results.
Automation is a major part of DevSecOps, and this requires the use of multiple software applications and tools. For example, companies use a variety of different application security testing tools (ASTs), which are essential to ensure that the code being used in development is safe and to prevent malicious packages from being introduced. These tools can be static (SAST), dynamic (DAST), and interactive (IAST) and they can also be from different vendors. Some may include automated vulnerability detection, prioritization, and even remediation capabilities that can address issues without requiring IT staff to spend much time researching vulnerabilities. The lesson: Many different tools are used in DevSecOps, and these will likely change as new innovations are introduced. Stay informed and updated on industry trends, especially if you are early in your journey because the tools and needs of today might be very different in a few years’ time. The idea behind shifting left and DevSecOps is to break down the traditional separation between developers, security, and IT professionals.
Google is skeptical about the complete disruption of Glupteba's operations. It says: "The operators of Glupteba are likely to attempt to regain control of the botnet using a backup command and control mechanism that uses data encoded on the Bitcoin blockchain." The botnet also has a feature that allows it to evade traditional takedowns. TAG says that a conventional botnet-infected device looks for predetermined domain addresses that point to the C2 server. The instructions to locate these domains are hard-coded in the malware installed on the victim's device. If the predetermined domains are taken down by law enforcement agencies or others, the infected devices can no longer receive instructions from the C2 servers and therefore can no longer be operated by the bot controller. The Glupteba botnet, however, does not rely solely on predetermined domains to ensure its survival, the TAG researchers. They say that when the botnet’s C2 server is interrupted, Glupteba malware is hard-coded to search the public Bitcoin blockchain for transactions involving three specific Bitcoin addresses that are controlled by the Glupteba botnet operators.
We often model processes to document them, to validate them with stakeholders, to teach them to others – and most of all, to improve them. In far too many companies, what they do and why they do it is implicit, not communicated well, and invites plenty of competing points of view as to what it really is. You need to tackle the process first before you attempt to automate any of its tasks. Not doing so would be like digging holes with a crane instead of a shovel, but without thinking about whether the holes are being dug in the right places (or should be dug at all). It’s not enough to think about saving time and money. Automating a process (not just its activity) documents it, makes it teachable and scalable, and goes a long way to reducing or eliminating mistakes (high profile errors can be a major catalyst for process automation). It also makes a process easily audited and monitored And it’s a lot easier to figure out how to improve a process you can see. And improvement is a must; if there’s one thing to expect when it comes to process automation, it’s change.
Quote for the day:
"Great Groups need to know that the person at the top will fight like a tiger for them." -- Warren G. Bennis