How should we regulate DeFi?
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.
How to make agile actually work for analytics
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.
Cloudentity SaaS platform enables zero trust access control for APIs
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.
SaaS DR/BC: If You Think Cloud Data is Forever, Think Again.
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.
Starting an SRE Team? Stay Away From Uptime.
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.
An opportunity is coming to drive up the number of women in tech
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.
Is the “great resignation” coming for you?
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.
DevSecOps jobs: 3 ways to get hired
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 TAG Disrupts Blockchain-Enabled Botnet
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.
You’re Doing it Wrong: It’s Not About Data and Applications – It’s About Processes
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
No comments:
Post a Comment