Ethical AI isn’t the same as trustworthy AI, and that matters
Certainly, unethical systems create mistrust. It does not follow, however,
that an ethical system will be categorically trusted. To further complicate
things, not trusting a system doesn’t mean it won’t get used. The capabilities
that underpin AI solutions – machine learning, deep learning, computer vision,
and natural language processing – are not ethical or unethical, trustworthy,
or untrustworthy. It is the context in which they are applied that matters.
.... The scale at which an AI pundit can be deployed to spread disinformation
or simply influence the opinions of human readers who may not realize the
content’s origin makes this both unethical and unworthy of trust. This is true
even if (and this is a big if) the AI pundit manages to not fall prey to and
adopt the racist, sexist, and other untoward perspectives rife in social media
today. ... Ultimately, ethics can determine whether a given AI solution sees
the light of day. Trust will determine its adoption and realized value. All
that said, people are strangely willing to trust with relatively little
incentive. This is true even when the risks are higher than a gelatinous
watermelon cookie. But regardless of the stakes, trust, once lost, is hard to
regain.
As technology develops in education so does the need for cybersecurity
One of the most effective ways to boost cybersecurity in education is by
adopting a proactive mentality, rather than a reactive one. Schools cannot
afford to wait until an attack happens to put processes in place to defend
themselves. Instead, they need to create a “cyber curriculum” that informs
everyone – IT teams, teachers, and students alike – about staying secure
online. This curriculum should include documentation that people can refer to
at any time, guiding them on the risks and warning signs of cyber attacks, as
well as best practices for smart online use. Likewise, the curriculum should
include on-demand training courses, current cybersecurity news and trends, and
the contact information for the people who are responsible for taking action
if the network is compromised. At the same time, IT admins need to be
conducting regular penetration tests and appoint a “red team” to expose
possible vulnerabilities. This team should test the school’s system under
realistic conditions and without warning, so as to identify weaknesses that
may not be immediately obvious.
After early boom, fintech lending startups face a reality check
Industry experts pointed out that from here on, the lending startups will
exercise abundant caution. There are a couple of points playing out in the
industry; first, there is availability of liquidity in the system; secondly,
there is demand since consumers need credit to restart their lives. The
repayment stress will continue well into 2021. Also, larger, well-capitalised
players might show a higher risk appetite and grab market share next year,
leading to some loss in business for fintechs, who might want to conserve
capital and recover existing loans. In a report titled ‘NBFC Sector in India:
A brief update post Covid’, consultancy firm Alvarez and Marsal pointed out
that that 10-15 percent of the customers who opted for a moratorium could see
defaults, thereby pushing up overall NPA numbers by 300-400 basis points.
Around 50 percent of those who took the moratorium could opt for restructuring
of their loans and lenders could see a spike in their credit costs, too, the
report added. There is already a spurt in demand for gold loans, which is a
secured form of personal loan. Bankers in the know pointed out that they are
more comfortable giving out secured loans in the aftermath of the pandemic,
given that consumers across the board could be in tough financial situations.
Infer# Brings Facebook's Infer Static Analyzer to C# and .NET
Infer is a static analysis tool open-sourced by Facebook in 2015. It supports Java and C/C++/Objective-C code and is able to detect a number of potential issues, including null pointer exceptions, resource leaks, annotation reachability, missing lock guards, and concurrency race conditions in Android and Java code; and null pointer dereferences, memory leaks, coding conventions, and unavailable API’s for languages belonging to the C-family. Infer# is not the only static analyzer available for .NET, says Microsoft senior software engineer Xin Shi. However, Infer# brings unique capabilities to the .NET platform. What sets Infer# apart is its focus on cross-function analysis, which is not found in other analyzers, and incremental analysis. PreFast detects some instances of null derereference exceptions and memory leaks, but its analysis is purely intra-procedural. Meanwhile, JetBrains Resharper heavily relies on developer annotations for its memory safety validation. ... The advantages of working from a low-level representation of the source code are twofold: first, the CIL underlies all .NET languages, and therefore InferSharp supports all .NET languages this wayDevSecOps Can Address the Challenges of Governance, Risk, Compliance (GRC)
DevOps originated within IT to meet similar performance and innovation goals.
While security and compliance have always been a part of DevOps, the term
DevSecOps is often used to ensure security is explicitly emphasized. Seeing
DevSecOps as part of a broader GRC framework makes clear how DevSecOps serves
the needs of organizations to innovate faster, maintain complete visibility
and control, and effectively manage risk. GRC and DevSecOps use different
tools, require different skills, follow different processes, and are
emphasized by different teams. But their goals are aligned, and it’s important
for both teams to appreciate this so they can collaborate effectively. DevOps
specialists are often narrowly focused on process automation or improving
handoffs within IT. It’s important for IT teams to appreciate their work in
the broader context of serving the company’s GRC initiatives. By contrast,
GRC-focused consultants and leaders need to understand DevSecOps as a
complementary approach that they should encourage, not inhibit. The IT
industry evolves faster than most departments in the company, so compliance
officers should defer to IT teams on the most efficient methods to meet
requirements. Their main role should be to emphasize the goals and
requirements of GRC, and to invite creative solutions from IT.
Best Practices for Building Offline Apps
On the flip side, some features are non-negotiable: you simply have to be
connected to the internet to use them, such as location services. That’s OK!
Identify what features need an internet connection, then create messages or
alerts informing those features’ needs to users. Users will appreciate it
because you’ll take the guesswork out of understanding your app’s limits when
offline. Conflicting information can be a big problem. It may not be enough to
simply merge and override all changes except the last time a user was online.
Users should have a clear understanding of what happens when conflict is
unavoidable. Once they know their options, they can choose what works for
them. There are several solutions for handling conflicting information. It is
up to you if you want the user to pick and choose which version to keep or to
institute a “last write wins” rule. No matter what you choose, the app should
handle this gracefully. Update too frequently and you may miss out on the
benefits of being offline first. Update too slowly and you may create more
conflicts than necessary and frustrate users.Knowing what to update along with
when to update is an important consideration as well.
Data anonymization best practices protect sensitive data
Before developing policies and procedures, buying products or implementing
manual data anonymization processes, identify all potential PII data
elements in your organization. The larger your environment, the more
susceptible your organization will be to storing unidentified PII data. This
isn't an easy task. Most data including PII doesn't sit idle. Once a data
element is created, it quickly spreads to reports, dashboards and other data
stores across an organization. Ensuring a person's continuous anonymity
throughout an enterprise is inherently fluid by its nature. In other words:
things change. Data audits and continuous feedback from IT and business
personnel that interact with PII will help to identify potential issues.
From products that specifically focus on data anonymization best practices
to enterprise-wide offerings that provide a wide range of data security
features, there is wealth of software solutions available. The larger an
organization is, the more important these tools become. Based on the amount
of data your organization stores, you may need to purchase a product or two
to properly identify and safeguard sensitive PII data assets. There is a
broad spectrum of data anonymization products that are available. In
addition, some existing data storage platforms inherently provide
anonymization features.
Quarterbacking Vulnerability Remediation
As the quarterback, security teams identify the nature of the vulnerability,
the business assets most at risk, the potential impact on the enterprise, and
the patch, configuration change, or workaround that will resolve the breach.
Armed with this knowledge, they pull in the right players from other IT
functions, align on the necessary fix, and coordinate the remediation
campaign, efficiently and effectively. When security and IT teams align on a
remediation strategy, the shared context and agreement on execution provides
the foundation needed to remediate vulnerabilities at scale. Even if the fix
goes wrong, problems get resolved faster when the lines of communication are
open. Fixing complex vulnerabilities often requires multiple coordinated
elements. The Boothole vulnerability is an excellent example of this:
Boothole's sheer pervasiveness makes it incredibly difficult to patch in
enterprise settings. It's a cross-platform vulnerability that requires both
hardware and software fixes — including firmware and OS updates — that must be
performed in precise order. Security, DevOps, and IT teams must work together
to minimize its business impact and avoid compromise. As the quarterback, the
security team needs to think and act like a team captain: What's the best
approach?
CIOs are facing a mental health epidemic
A degree of stress for a CIO is expected and unavoidable in any change
project. However, businesses are currently failing to manage this pressure
effectively. Recent independent research conducted on behalf of Firstsource
found that 55% of business leaders wished they had managed the emotional
marathon of change projects better. And CIOs identified the three biggest
causes of stress as: 1. Not having the right mix of skills in the
team; 2. Pushing too hard and harshly without taking time to celebrate
wins; and 3. Resistance from key stakeholders in other divisions and
countries. To support CIO’s digital transformation, the research spoke with
120 business leaders to understand how to turn challenges into catalysts for
success. This resulted in the emergence of a framework with five areas that
are key to managing stress and ensuring a transformation project’s success.
Proactively addressing these five areas will help CIOs deliver projects that
unlock the full potential of their businesses while managing the stress
levels of teams. Managing the business case optimism: CIOs will always aim
to keep transformation projects realistic and grounded. However, business
cases are never static.
5 things CIOs want from app developers
It’s very easy for development teams to get excited chasing innovations or
adding spikes around new technologies to the backlog. CIOs and IT leaders
want innovation, but they are also concerned when development teams don’t
address technical debt. A healthy agile backlog should show agile teams
completing a balance of spikes, technical debt, new functionality, and
operational improvements. Prioritization on agile teams should fall to
the product owner. But IT leaders can establish principles if product owners
fail to prioritize technical debt or if they force feature priorities
without considering the agile team’s recommended innovation spikes. CIO and
IT leaders are also realistic and know that new implementations likely come
with additional technical debt. They understand that sometimes developers
must cut corners to meet deadlines or identify more efficient coding options
during the implementation. It’s reasonable to expect that newly created
technical debt is codified in the source code and the agile backlogs, and
that teams seek to address them based on priorities. Development teams are
under significant pressure to deliver features and capabilities to end-users
quickly. That is certainly one reason teams create new technical debt, but
it’s a poor excuse for developing code that is not maintainable or that
bypasses security standards.
Quote for the day:
"Coaching isn't an addition to a leader's job, it's an integral part of it." -- George S. Odiorne
