Blog

Posted on

The AI Calculus – Where Do Ethics Factor In?

While artificial intelligence and machine learning deployment are on the rise – and generating plenty of buzz along the way – organizations face difficult decisions about how, where and when to introduce AI.

In a session Tuesday at the 2018 GRC Conference in Nashville, Tennessee, USA, co-presenters Kirsten Lloyd and Josh Elliot laid out many of the ethical considerations that should be part of those deliberations.

The pair detailed several instances of high-profile AI events over the past decade that highlighted the need to give ethical components of AI deployment a high level of focus early in a product or service’s design, as opposed to risking unforeseen fallout. The examples included the development of a controversial algorithm that predicted higher rates of recidivism for black defendants in the judicial system and a Stanford University study exploring how often AI could determine a person’s sexual orientation based on photos of their faces.

Yet, for all of the questionable or even potentially malicious use cases of AI, Lloyd and Eliot highlighted an extensive list of powerfully compelling uses for AI, such as advancing new medical treatments, preventing cyber attacks, improving energy efficiency and increasing crop yields. Elliot, Booz Allen Hamilton’s director of artificial intelligence, noted that AI also may prove transformative in missing person crises, such as being able to swiftly locate missing children in AMBER Alert child abductions.

Whether the potential ethical implications of AI and machine learning outweigh the good that can be accomplished is very much a case-by-case judgment call, Elliot said, requiring a holistic evaluation of the possible outcomes through a risk management lens. Successful, ethical implementation of AI and machine learning also call for strong governance, with emphasis on benefits realization, risk optimization and resource optimization. Elliot and Lloyd said organizations should identify and engage key stakeholders in AI projects, including the creation of an ethical review board and a chief ethics officer. Some high-impact deployments might also require direct access to the C-Suite for input on risk considerations.

Elliot and Lloyd suggested that organizations consider the following questions when deciding how they might want to deploy AI and machine learning:

  1. What are our goals?
  2. How much risk are we willing to tolerate?
  3. What is the state of our data assets?
  4. What talent assets do we have?
  5. What are our values?

From a people talent standpoint, Elliot noted there is a serious shortage of professionals with the expertise to help enterprises effectively and securely implement AI and machine learning, causing many organizations to turn to the ranks of academia and research to fill in the personnel gaps. Lloyd, an AI strategist with Booz Allen Hamilton, acknowledged the workforce worries many harbor regarding the potential for AI and machine learning to displace large numbers of practitioners, but said that there will remain an enduring need for humans’ critical thinking skills, while machines continue to introduce process improvements in computational thinking.

Taking the long view, Elliot and Lloyd said AI and related disciplines have transitioned from their previous state of simple task execution to the current era of pattern recognition, with a future that will be reshaped by added capabilities of contextual reasoning. Elliot said many of today’s common uses, such as robotic process automation (RPA), are a mere “gateway drug” to more sophisticated technologies and applications that are being aggressively researched in Silicon Valley and beyond.

[ISACA Now Blog]

Posted on

Four Unit 42 Vulnerability Researchers Make MSRC Top 100 for 2018

Palo Alto Networks Unit 42 is proud to announce that four of our researchers were named to the Microsoft Security Response Center (MSRC) “Top 100 Security Researchers List” for 2018. This is the third year Unit 42 researchers have been included in this prestigious list, which is announced every year at Black Hat. This year’s Unit 42 winners are:

 

Rank Name
10 Gal De Leon
13 Hui Gao
73 Tao Yan
79 Jin Chen

 

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android and other ecosystems. By proactively identifying vulnerabilities, developing protections for our customers, and sharing them with Microsoft for patching, we are removing weapons used by attackers that compromise enterprise, government and service provider networks.

Below is the full list of this year’s top 100. To better understand how this recognition is both important and an honor, this posting by Phillip Misner of the MSRC gives you an idea of what’s behind the program.

[Palo Alto Networks Research Center]

Posted on

In OT Environments, Security Must Not Be an Afterthought

The dream of a cloud-enabled operational technology, or OT, environment is becoming a reality thanks to daily innovations in technology, which have the potential of turning legacy control systems into integrated IIoT instances. These changes are happening at a fast pace, and are often extraordinary in scale. Large scale ICS SCADA systems, such as those found in oil and gas are evolving; however, one thing remains constant: poor security.

 

Why Security Is a Challenge

As IT security professionals know, security must adapt to an ever-changing threat landscape. A fluid model does not play well with most current ICS and SCADA systems. These systems depend on availability first, making the application of security measures challenging to implement and even harder to maintain. For OT operators, security must support a model that allows technicians to connect devices first to configure and fine-tune them, and then later lock them down. There must be enough security in place to protect both the business and the process control environment from attacks, but with just enough protection that it neither overcomplicates the automation groups workflows nor stops, blocks or disrupts production.

Purpose-built and expensive to update or replace, these systems and networks do not conform to the equipment lifecycle of an IT network. The majority of oil and gas field networks and remote process control networks are archaic, but also happen to be the systems we take for granted on a daily basis. Attackers know that, when and if these systems fail, they can affect our daily lives.

 

What’s Next?

It is time we change our beliefs on what a secure network looks like and how it should work? As organizations adopt cloud-based infrastructures and other IIoT technologies, security does not have to be an afterthought. Our Security Operating Platform secures control system networks in several ways, including automatically preventing new and unknown threats, providing virtual network segmentation and offering role-based network access.

Learn more about how to protect your controls environment against sophisticated cyberattacks by downloading our Cybersecurity for Oil and Gas Solutions Brief.

[Palo Alto Networks Research Center]
Posted on

Threat Brief: Cyber Attackers Using Your Home Router To Bring Down Websites

In recent research, Palo Alto Networks found attackers were targeting home routers to take control and use them for attacks against other websites that can bring them down. Here we explain this type of attack and what you should do.

 

Why should I care, what can it do to me?

These attacks could affect you in two ways:

  1. They can slow down or disrupt your internet connection,
  2. They can also make you an unwitting participant in attacks against other websites.

 

What causes this kind of attack?

Weak passwords and out-of-date software can both enable attackers to take complete control of your home router.

 

How can I prevent it?

Attackers target home routers like this by targeting default passwords and out-of-date software on the routers. An easy thing you can do is restart your router once a week (typically by unplugging it).

You can also stay safe by changing the password on your router and updating the software. If you’re not sure how to do this, contact your Internet Service Provider (ISP) that gave you the router for help.

 

How does it work?

When devices (in this case, the routers) are under someone else’s control like this, the collection is referred to as a “botnet”, a network (-net) of remotely controlled systems or devices (bot-).

When attackers have complete control of your home router, they can install attack software that they control, turning the device into a “bot”. Attacks can make all the controlled routers in a botnet do anything they want, including sending huge amounts of data to try and bring websites down.

These kinds of attacks are called “Distributed Denial of Service” or “DDoS” attacks. Attackers use them to take down websites for several reasons:

  • Personal or political reasons
  • To blackmail websites to pay money or face attack
  • To act as a diversion for other more serious attacks
  • Simply to create mischief

 

About

Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.

They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.

Got a topic you want us to write about for you, your friends, or your family? Email us at u42comms@paloaltonetworks.com.

[Palo Alto Networks Research Center]

Posted on

CVE and Cloud Services, Part 1: The Exclusion of Cloud Service Vulnerabilities

The vulnerability management process has traditionally been supported by a finely balanced ecosystem, which includes such stakeholders as security researchers, enterprises, and vendors. At the crux of this ecosystem is the Common Vulnerabilities and Exposures (CVE) identification system. In order to be assigned an ID, vulnerabilities have to fulfill certain criteria. In recent times, these criteria have become problematic as they exclude vulnerabilities in certain categories of IT services that are becoming more and more common.

This is the first in a series of blogposts that will explore the challenges and opportunities in enterprise vulnerability management in relation to the increasing adoption of cloud services.

Common Vulnerabilities and Exposures

CVE® is a list of entries, each containing an identification number, a description, and at least one public reference for publicly known cybersecurity vulnerabilities[1].

CVEs are identifiers for security vulnerabilities that are—or are expected to become—public. Traditionally, they are assigned by one of two entities: The CNA (CVE Numbering Authority) that exists specifically for that piece of software (e.g. Microsoft, which covers Microsoft software) or a CNA that has been given coverage of said software (e.g. The Debian Project, Distributed Weakness Filing Project, and Red Hat all cover Open Source software to varying degrees). These CVEs are then published in the MITRE CVE database. Finally, they are consumed and republished by other organizations, often with additional information such as workarounds or fixes which makes tracking and remediating those vulnerabilities possible.

Customers of companies or organizations that are CNAs for their own products can be reasonably assured that CVE IDs are assigned to historical, current and future vulnerabilities found in those products.

CVE and Vulnerability Management

The CVE system is the linchpin of the vulnerability management process, as its widespread use and adoption allows different services and business processes to interoperate. The system provides a way for specific vulnerabilities to be tracked via the assignment of IDs. Enterprises, security researchers, penetration testers, software providers and even vulnerability scanning tools all use CVE IDs to track vulnerabilities in products. These IDs also allow important information regarding a vulnerability to be associated with it such as workarounds, vulnerable software versions, and Common Vulnerability Scoring System (CVSS) scores. Without the CVE system, it becomes difficult to track vulnerabilities in a way that allows the different stakeholders and their tools to interoperate.

Fig 1: Example of CVE and other associated information taken from CVEdetails.com (https://www.cvedetails.com/cve/CVE-2007-0994/)

CVE Inclusion Rules and Limitations

The decision to assign an ID to a vulnerability is governed by the Inclusion Rules. In order to assign a CVE ID to a vulnerability, the assigner has to take the vulnerability through the Inclusion Rules. Generally, only a vulnerability that fulfills all five criteria will be assigned an ID. For example, one of the Inclusion rules, INC3, states that a vulnerability should only be assigned a CVE ID if it is customer-controlled or customer-installable. A vulnerability in a Customer Relationship Management (CRM) software that is installed on a server owned and managed by an enterprise fulfills that requirement.

Fig 2: Inclusion Rule INC3 taken from cve.mitre.org (https://cve.mitre.org/cve/editorial_policies/counting_rules.html)

INC3, as it is currently worded, is problematic for a world that is increasingly dominated by cloud services. In the past, this inclusion rule has worked well for the IT industry as most enterprise IT services have generally been provisioned with infrastructure owned by the enterprise. However, with the proliferation of cloud services, this particular rule has created a growing gap for enterprise vulnerability management. This is because cloud services, as we currently understand them, are not customer controlled. As a result, vulnerabilities in cloud services are generally not assigned CVE IDs. Information such as workarounds, affected software or hardware versions, proof of concepts, references and patches are not available as this information is normally associated to a CVE ID. Without the support of the CVE system, it becomes difficult, if not impossible, to track and manage vulnerabilities.

Conclusion

The Cloud Security Alliance and the CVE board are currently exploring solutions to this problem.

One of the first tasks is to obtain industry feedback regarding a possible modification of INC3 to take into account vulnerabilities that are not customer-controlled. Such a change would officially put cloud service vulnerabilities in the scope of the CVE system. This would not only allow vulnerabilities to be properly tracked, it would also enable important information to be associated with a service vulnerability.

Please let us know what you think about a change to INC3 and the resulting impact on the vulnerability management ecosystem in the comment section below or you can also email us.

Stay tuned for our next blog post where we will explore the impacts that the current Inclusion Rules have on enterprise vulnerability management.

[1] https://cve.mitre.org/

Kurt Seifried, Director of IT, Cloud Security Alliance and Victor Chin, Research Analyst, Cloud Security Alliance

[Cloud Security Alliance Blog]

English
English
Exit mobile version