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.
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.
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.
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.
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.
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.
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?
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.
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