Ethics

Cybersecurity professionals often operate in roles that require trust, and where specialised knowledge and skills may give them the ability to influence or interfere with the affairs of their clients or other people. Actors outside client relationships, such as product developers and academic researchers, apply specialised skills in ways that may cause harm to many third parties. The activities of these professionals often take place behind closed doors, far from public oversight. Ethical norms can help reduce the likelihood of misusing a position of trust or otherwise creating significant risk to the public.

Early ethical guidelines in cybersecurity focused significantly on managing legal risks, such as liabilities associated with laws concerning intellectual property and privacy. Although professionals must remain aware of the laws governing their activities, compliance with the law alone may be insufficient to guide ethical conduct.

Cybersecurity professions are generally practised without formal regulation or licensing, unlike, for example, the medical profession. It is therefore difficult to identify generalisable norms that should be applied by actors in the security field. This module examines some key phenomena and possible sources of guidance.

Obligations towards the client

When professional communities in cybersecurity develop ethical norms, they may draw inspiration from the types of obligations owed to clients in regulated professions. At a minimum, one can identify various duties of care grounded in contract or tort law, according to which services and other risky activities must be carried out in a reasonable manner and with sufficient expertise. Product designers already have legal obligations under general liability rules.

Regulated professionals are generally expected to act in the interests of their clients, avoid conflicts of interest, and maintain the confidentiality of client relationships. Although accepting such obligations by contract is often uncontroversial, difficulties may arise when the security practitioner and the client disagree on the most appropriate course of action in specific circumstances.

Challenges may arise concerning the voluntary disclosure of evidence to third parties. If a practitioner discovers evidence of misconduct and there is no legal duty to report it, the practitioner and the client may disagree. Highly interested third parties may include a law enforcement authority, a CERT, or a party entitled to damages. Navigating such situations can be difficult. In the case of economic crime against the client (e.g. minor theft), the client may consider publicity more harmful than handling the matter solely through internal disciplinary procedures. In cases where an employee is found to have harmed a third party through actions giving rise to liability, such as negligence, disclosure of evidence to the victim may harm the client’s business.

Other difficult cases arise when the interests of the practitioner and the client are not aligned. Some systems of professional ethics, for example, allow a regulated professional to disclose parts of a client’s confidential information in the course of debt collection, for instance by bringing an action for breach of contract related to the provision of confidential services. Such disclosures must typically be limited to the information necessary to carry out the recovery and may involve a duty to request appropriate protective orders from the court.

The actions of a practitioner in, for example, penetration testing, may disrupt the operation of the client’s infrastructure. Even when agreed in a contract, such actions are at best unpleasant and may at worst fulfil the elements of a criminal offence. This may not necessarily be mere incompetence; it may also involve an unethical attempt by the practitioner to influence the client. Threatening such actions, directly or indirectly, is no more acceptable.

It remains to be seen whether relationships between cybersecurity professionals and clients will eventually come under formal regulation or licensing.

Codes of ethics

Various professional communities have published codes of conduct and ethical guidelines for cybersecurity professionals. Many of them refer to high-level ethical principles without providing the detailed guidance needed to assist in their interpretation. Below are examples of two relatively recent and carefully considered codes. One is formulated for general application and the other is structured around a defined business process.

The Association for Computing Machinery (ACM) originated alongside computers themselves. It has more than 100,000 members. The ACM Code of Ethics and Professional Conduct was extensively revised in 2018 to better take into account the effects of advanced data connectivity. The revised ACM Code provides several guidelines relevant to cybersecurity. ACM also offers additional material to assist in understanding and applying the code.

The ACM Code clearly illustrates the difficulty of balancing ethical requirements. In its call to avoid harm (section 1.2), it states that there is “an additional obligation to report any signs of system risks that might result in harm”. While the code discusses the possibility of whistle-blowing as a reporting technique under certain circumstances, it also warns that “capricious or misguided reporting of risks can itself be harmful. Before reporting risks, a computing professional should carefully assess relevant aspects of the situation.”

A very different organisation is CREST. It was founded in England in the early 2000s and was originally an association of companies providing penetration testing. In 2019, it had over 180 accredited member companies. Penetration testing is a typical example of a cause-for-concern service: clients are generally unable to distinguish good practices from bad ones; services are provided confidentially outside public oversight; and practitioners’ errors may cause disproportionate harm to clients or third parties. CREST offers professionals competence certifications that give clients a good indication at least of skills. One requirement for certification is adherence to the CREST code of ethics. It provides guidance on numerous aspects of delivering these services, including service methods, ethical business practices, and obligations to clients. CREST offers clients a complaints mechanism and reserves the right to expel members who do not comply with the CREST code. To the extent that clients begin to require service providers to maintain CREST membership, their commissioning practices may gradually transform CREST from a purely voluntary organisation into a de facto regulator of these service providers.

General-level codes are useful in guiding the broad community of cybersecurity professionals, people who may work in fields as varied as research and development or security management. Service-specific codes are useful in focusing clearly on particular high-risk services. Different codes will undoubtedly continue to evolve as the impacts of cybersecurity professionals’ activities are more thoroughly understood.

Vulnerability testing and disclosure

Vulnerabilities are sought in information systems and disclosed. Both give rise to ethical issues.

Vulnerability testing

Those searching for security flaws must understand the nature of their activities. Ethical issues usually do not arise when examining tangible hardware products, licensed software located on one’s own equipment, published cryptographic primitives, or communication protocols. Even where the target is reverse engineering of the same closed cryptosystem, legality may differ depending on the target environment. Such a situation arose in 2013 for researchers who discovered a vulnerability in Volkswagen’s immobiliser system and were prosecuted for its disclosure. They had not examined the operation of the cryptosystem in the device itself but in third-party software (Megamos; see the article).

When vulnerability testing is carried out remotely, gaining access to an information system may constitute a criminal offence. The ACM Code (section 2.8) states that the public availability of a system does not in itself imply authorisation to access it. Participants in “bug bounty” programmes must also understand the terms carefully to avoid exceeding their authorisation.

Testers should weigh the potential impact of their methods on the stability of public or private infrastructure, both in the target system and in the systems of intermediaries and other third parties.

Disclosure of vulnerabilities

A discoverer of a vulnerability must decide what to do with the new information. The range of options is broad. At the extremes are keeping the information private and publishing detailed information immediately to the entire world.

Some choose not to disclose information in order to avoid complex ethical issues and potential liability. This position is difficult to reconcile with the ethical principle expressed in section 2.8 of the ACM Code, according to which system risks that may cause harm should be reported.

An actor close to a national security agency may choose to keep the information secret after concluding that the risks and benefits of disclosure are greater than those of confidentiality. The ethics of this balancing exercise remain a subject of ongoing debate.

Those who publish immediately without prior warning may do so for various reasons. Some consider this the only reliable way to encourage developers to take corrective action. Others do not wish to spend time on the private and public notification processes described below. Still others fear that contacting developers may trigger legal intervention preventing disclosure. These perspectives are difficult to reconcile with the guidance of the ACM Code. Many practitioners follow a principle known as responsible disclosure. The idea is to first inform, confidentially, parties who may be able to fix the vulnerability or mitigate its impact. After a suitable period has elapsed, the discoverer may publish the findings. The rationale is that disclosure allows other practitioners to examine and avoid similar vulnerabilities and/or encourages providers of products and services to remedy the vulnerability. However, there do not appear to be universally accepted principles for the proper conduct of responsible disclosure. Points of divergence include:

• how to manage private disclosure when the vulnerability
  • is part of a widely adopted industry standard;
  • is found in a product that forms part or a component of downstream products;
• determining an appropriate period between private and public disclosure;
• defining the circumstances that require postponing public disclosure;
• choosing a course of action if the suppliers or buyers of affected products disagree with the discoverer on the wisdom or timing of disclosure.

Public disclosure of vulnerabilities may also give rise to liability for damages for the disclosing finder, especially if the disclosure process is poorly managed or the vulnerability is mischaracterised.

“Responsible disclosure without consideration” is not necessarily a principle accepted by law enforcement authorities, as illustrated by the VW–Megamos case mentioned above.

Efforts to obtain financial benefit from disclosure also generate debate. Accepting financial rewards under a “bug bounty” programme published by a manufacturer appears to be widely accepted, particularly where the manufacturer controls the programme terms. More controversial tactics include:

• requesting a reward from the manufacturer as a condition for reporting the vulnerability;
• selling information about the vulnerability to a broker of such information;
• engaging in share trading or other transactions that become profitable due to prior knowledge of a problem soon to be disclosed.

If the vulnerability has been discovered as part of a security researcher’s employment, any reward obtained may not belong entirely to the discoverer.

Vulnerability disclosure practices

Product and service vendors should plan how they can facilitate the receipt of information about vulnerabilities and respond to them in a way that minimises the harm caused by the vulnerabilities.

Good principles for this would be that the vendor

• specifies acceptable methods by which vulnerability finders can report their findings;
• makes an effort to verify the vulnerability after its disclosure;
• develops corrective or mitigating procedures;
• distributes fixes;
• works with supply chain partners; and
• provides feedback to the finder.

Guidance for developing practices and processes can be found in the standards ISO/IEC 29147 (receiving and handling information on vulnerabilities) and ISO/IEC 30111 (vulnerability verification and remediation process). In some countries, government agencies have also published guidelines on this topic.

Question 1

Compliance with the law alone may be insufficient to guide a cybersecurity professional towards ethical conduct because

ethical conduct implies activity, that is, broader action than merely doing the minimum required.

laws define only crimes and punishments, and do not actually require doing anything.

there are many situations in which a professional in a position of trust, or acting outside client relationships, may cause harm to others without breaking the law.

compliance with the law requires only knowledge, that is, no deeper understanding and certainly no empathy is needed.

Question 2

What kind of ethical regulation exists in the information security field?

Most information security professions are regulated in the same way as the medical profession and are subject to similar rules, including confidentiality obligations.

Only a few information security professions are regulated in the same way as the medical profession, but with regard to data protection, the GDPR sets ethical rules for all information security professionals operating in the EU.

There is no rule in information security professions comparable to legal professional privilege for lawyers, but similar objectives are achieved through contracts with clients.

In the United Kingdom, one cannot perform penetration testing professionally without committing to comply with the CREST code.

Question 3

Responsible disclosure of a vulnerability

is a two-stage process whose principles are well established.

is a process whose first stage typically involves disclosing the information to the system’s manufacturer.

is a two-stage or multi-stage fully anonymised process.

does not require consideration if there is no party capable of fixing the vulnerability.

Question 4

Up to which option letter can the following text be read before it begins, under a conventional interpretation, to describe unethical conduct? “A cybersecurity professional examines an information system owned by someone else (a) in an offensive manner (b) with the aim of finding a vulnerability (c) and making money from it. (d) They also report the discovered information to an organisation that publishes vulnerabilities. (e)”

a

b

c

d

e

Posting submission...