Semantic classification of top-level information security related concepts

Dr Ph. MARTIN, January 2009

This file is in construction. It will represent and organize general information security concepts (and some top-level security concepts). The following files represent and organize specializations of these concepts:

The file about the P3P ontology can be seen as a complement to this file.
More requirements from my report on "security and RFID" (in French) will be integrated.

The representations are written in the FL notation (they are shown below in the courier font; they are enclosed within the XHTML marks <KR> and </KR> for permitting WebKB-2 to distinguish them from regular text). The creator (or source) of each representation (category or statement) is represented: the identifier "pm" is used for the author of this document

This file (or, more precisely, the representations within this file) has already been loaded in the knowledge base of WebKB-2. Hence, these representations can be queried, navigated and complemented by anyone using WebKB-2 (e.g., click on the hyperlinks below). This ontology reuses the ontology of WebKB-2, i.e. an extension and correction of WordNet 1.7.

Level 1-3 about security in general, implicit in titles of level 1 and 2. information security also everywhere even though most often implicit in titles

Table of contents

1.  General roles  -- (in-)security related roles playable by entities as well as situations;
                                threats (errors, failures, faults) are specialized in Section 3 of the Resist ontology
2.  Entities  -- (in-)security related things that are neither states nor processes
   2.1.  Attributes  (criterias)  -- availability, integrity, confidentiality, ...
   2.2.  Descriptions and description supports  -- statements, documents, languages, ...
      2.2.1.  Regulations
      2.2.2.  Policies  -- computer security policies/models, insurance policies, ...
      2.2.3.  Models and principles or strategies
      2.2.4.  Descriptions of controls or measures
      2.2.5.  Certifications (digital signatures, ...) and results of evaluations
      2.2.6.  Skill qualifications (diplomas, ...)
      2.2.7.  Policy languages
   2.3.  Agents
      2.3.1.  Organisations  -- professional organisations, standard sources, ...
      2.3.2.  Individuals  -- security professionals, hackers, ...
   2.4.  Instruments (devices, systems, ...)
      2.4.1.  Hardwares  -- security evaluated/focused/threatening hardwares
      2.4.2.  Softwares  -- security evaluated/focused/threatening softwares
3.  Situations  -- (in-)security related states or processes
   3.1.  States  -- situations that are not processes, e.g., safety and insecurity
   3.2.  Security threatening processes  -- attacking, eavesdropping, ...
   à  à  à -- The remaining sections are about "security supporting" processes
   3.3.  Managing  -- economic/sanitary/social/information risk management/engineering
   3.4.  Evaluating  -- security classification/evaluation
   3.5.  Designing
      3.5.1.  Applying design principles
      3.5.2.  Using cryptographic techniques
      3.5.3.  Supporting authentication and access controls
   3.6.  Satisfying criterias  -- supporting security needs
      3.6.1.  Supporting confidentiality
      3.6.2.  Supporting integrity
      3.6.3.  Supporting accessibility and interoperability
      3.6.4.  Supporting imputability
   3.7.  Fault tolerance/forecasting/prevention/removal  -- Section 4 of the Resist ontology

1.  General roles

security_related_thing   <  thing_playing_some_role,
  > {( security_related_entity  security_related_situation )}
    { (security_supporting_thing  >  threat  vulnerability  risk)
      (security_threatening_thing  >  fail-safe_thing)

     threat  (^anything (man made or act of nature) that has the potential to cause harm^)
       > error  failure  fault  //all specialized in Section 3 of the Resist ontology
         exploits  security_threatening_agent;  //this last one is specialized in the section titled "Agents"

         exploits (^software, a chunk of data, or sequence of commands that takes advantage of a bug, glitch or
              vulnerability in order to cause unintended or unanticipated behavior to occur on computer software,
               hardware, or something electronic (usually computerized) ^)

     vulnerability___security_hole___risk_source___risk (^weakness that could be used to endanger or cause harm^)
       >  software_vulnerability;

            >  software_bug  weak_password  code_injection

                 >  buffer_overflow  format_string_vulnerability  integer_overflow  

     risk  (^likelihood that something bad will happen;
             the likelihood that a threat will use a vulnerability to cause harm creates a risk;
             when a threat does use a vulnerability to inflict harm, it has an impact.
             in the context of information security, the impact is a loss of availability,
             integrity, and confidentiality, and possibly other losses^);
       >  residual_risk  risk_for_information  sanitary_risk  economic_risk  social_risk;

          residual_risk (^unidentified or non-eliminated risk^);


       >  #security.transferred_property;

2.  Entities

  exclusion:  security_related_situation,
  <  entity_playing_some_role,
  >  {security_supporting_entity  security_threatening_entity}
     security_related_attribute  security_related_description  security_related_agent

2.1.  Attributes  (criterias)

  supertype:  attribute_or_quality_or_measure,
  subtype:  security_attribute  assurance_level;

     security_attribute  (^Security qualities or attributes are often considered as "non-functional" requirements
                           when systems are designed. In other words they are not required for the system to meet
                           it's functional goals such as processing financial transactions, but are needed for a
                           given level of assurance that the system will perform to meet the functional requirements
                           that have been defined.^)
       > #accessibility   //  < #suitability < #quality 
         #integrity       //  < #honestness < #morality < #quality < #attribute
         #dependability   //  < #dependability < #trait < #attribute
         {#dangerousness  #safeness}  //  < #characteristic 
         dependancy_or_information_security_attribute  //developped in this other file
                                                       //  with subtypes specializing the above WordNet subtypes         
         #confidentiality.discreetness;  //  < #psychological_feature;

       <  security_supporting_entity,
       >  Common_Criteria_evaluation_assurance_level,

              (^numerical rating describing the security strength of a product in terms of
                security functionality and assurance level^)
            subtype:  EAL4  EAL5  B2  A1_CSC-STD-001-83,
            descr: Common_Criteria_certification,

2.2.  Descriptions and description supports

security_related_description  < pm#description,  //description_content/medium
  >  security_supporting_regulation  security_policy  security_model  security_principle
     security_measure_description  security_related_certification  security_evaluation_result_description
     security_supporting_skill_qualification  security_supporting_language;

2.2.1.  Regulations

/* security_supporting_regulation
     1.2.  Policy Resources/References/Instructions/Hints

2.2.2.  Policies

  >  computer_security_policy  #insurance_policy;

     computer_security_policy  (^definition of the goals and elements of an organization's computer systems^)
       subtype:  {formal_computer_security_policy  informal_computer_security_policy}
                 confidentiality_policy_model  integrity_policy_model  availability_policy_model
     //output of: writing_computer_security_policy //with a computer_security_policy_language

            subtype:  Bell-LaPadula_model;

            subtype:  Biba_model  Clark-Wilson_model;

            subtype:  Chinese_Wall_computer_security_policy_model;

2.2.3.  Models and principles or strategies

security_model  (^scheme for specifying and enforcing security policies^) 
  >  computer_security_model;

     computer_security_model (^it may be founded upon a formal model of access rights, a model of computation, 
                               a model of distributed computing, or no particular theoretical grounding at all^)

  supertype:  #principle,
  subtype: security_stance
           defense_in_depth_principle  security_cascading_principle  principle_of_least_privilege

       >  default-deny_security_stance  default-permit_security_stance ;

         default-deny_security_stance (^"everything, not explicitly permitted, is forbidden";
                                        this improves security at a cost in functionality;
                                        this is a good approach for dealing with lots of security threats^)

         default-permit_security_stance (^"everything, not explicitly forbidden, is permitted";
                                          allows greater functionality by sacrificing security;.
                                          only a good approach when security threats are non-existent or negligible^);

     defense_in_depth_principle (^more than one subsystem needs to be violated to compromise the integrity 
                                  of the system and the information it holds; the breaching of one security measure
                                  does not provide a platform to facilitate subverting another);

       (^cascading several weak mechanisms does not provide the safety of a single stronger mechanism^);

       (^every object (e.g., process, user or program) must be able to access only information and resources
         that are necessary to its legitimate purpose^)
       subtype:  principle_of_least_user_access___principle_of_least-privileged_user_account,

         principle_of_least_user_access (^every user at all times should run with as few privileges as possible,
                                          and also launch applications with as few privileges as possible^)

     fail_secure_principle (^subsystems should default to secure settings, and wherever possible should be 
                             designed to "fail secure" rather than "fail insecure"; ideally, a secure system 
                             should require a deliberate, conscious, knowledgeable and free decision on the
                             part of legitimate authorities in order to make it insecure.^)
       url:;  //safety engineering

2.2.4.  Descriptions of controls or measures

  >  information_security_measure_description;

         (^description of where security measures/controls are (or need to be) positioned and 
           how they relate to the overall IT Architecture^)

2.2.5.  Certifications (digital signatures, ...) and results of evaluations

  <  #certificate         //  <  (#legal_document    < pm#description_content)
     #security.warranty,  //  <  (#assurance___pledge < #commitment.subject_matter, > #security.pledge)
  >  digital_signature  certification_from_a_security_auditing_organization;

       <  #assay-mark,   // < (#signal < #communication < pm#description_content/medium/container #social_relation)

       subtype:  Common_Criteria_certification,

  >  certification_from_a_security_auditing_organization

       subtype:  Common_Criteria_evaluation_assurance_level  Common_Criteria_security_assurance_requirements

             (^descriptions of the measures taken during development and evaluation of the product
               to assure compliance with the claimed security functionality^);

             (^numerical rating describing the security strength of a product in terms of security functionality and assurance level^)

              (^document about security features/requirements/levels of the product or system that is the Target Of Evaluation (TOE)^)
            supertype:  #document,
            subtype:  document_about_the_protection_profile_of_Common_Criteria_security_evaluation

                 (^document, typically created by a user or user community, identifying security requirements
                   for a class of security devices^)

                 (^document specifying individual security functions which may be provided by a product^);

                 (^document that identifies the security properties of the target of evaluation^)

2.2.6.  Skill qualifications

  >   SecurityPlus  Chartered_Professional_Engineer

2.2.7.  Policy languages

  >  computer_security_policy_language  security_supporting_programming_language;

//Domain Type Enforcement-Language

2.3.  Agents

  <  pm#causal_entity,
  >  {security_supporting_agent  security_threatening_agent}
     {security_related_organisation  security_related_individual};

       >  security_supporting_organisation   security_supporting_individual;

       <  #danger.causal_agent, // >  #menace.danger___threat  #jeopardy___hazard___peril___risk
       >  security_threatening_individual;

2.3.1.  Organisations

security_related_organisation  < #organization,
  >  security_supporting_organisation;

       > security_supporting_standardisation_organism  security_auditing_organization
         organisation_of_security_supporting_professionals  #security.department;

           > organisation_of_information_security_professionals;

               object: information_security,
               > information_security_department  Information_Networking_Institute;

                 information_security_department  <  #security.department;

2.3.2.  Individuals

security_related_individual  < #person,
  >  {security_supporting_individual  security_threatening_individual};

       >  security_supporting_professional;

            > information_security_professional;

                member of: organisation_of_information_security_professionals,
                >  information_security_professional;

                     >  information_security_officer  information_security_scholar;

                          > information_security_engineer  information_security_manager;


       subtype: #hacker.computer_programmer;

2.4.  Instruments (devices, systems)

  <  #instrument.tool,
  >  {security_supporting_instrument  security_threatening_instrument}
     {security_related_hardware  security_related_software};

      >  information_security_supporting_instrument;

           >  firewall   information_security_supporting_software;

              firewall (^dedicated appliance, or software running on another computer, which inspects network 
                        traffic passing through it, and denies or permits passage based on a set of rules^)
                >  AVG_Plus_Firewall_Edition  Comodo_Firewall_Pro  McAfee_Personal_Firewall_Plus
                   Netfilter/iptables  Norton_Personal_Firewall  Windows_Firewall  ZoneAlarm,

2.4.1.  Hardwares

security_related_hardware < pm#hardware,
  >  {security_supporting_hardware  security_threatening_hardware};

     security_supporting_hardware  < security_supporting_instrument,
       >  security_evaluated_hardware  security_focused_hardware;

     security_threatening_hardware  < security_threatening_instrument;

2.4.2.  Softwares

security_related_software  < #software,
  >  {security_supporting_software  security_threatening_software};

     security_supporting_hardware  < security_supporting_instrument,
       >  security_evaluated_software  security_focused_software

            supertype:  #operating_system,
            subtype:  security-evaluated_operating_system  security_focused_operating_system,

     security_threatening_software  < security_threatening_instrument;  Security evaluated softwares

  >  security-evaluated_operating_system;

     security-evaluated_operating_system (^operating system that has achieved a certification from 
                                           an external security auditing organization^)
       subtype:  trusted_operating_system,

           trusted_operating_system__TOS  (^operating system providing sufficient support for multilevel security
                                      and evidence of correctness to meet a particular set of government requirements^)

           security_focused_BSD     subtype:  OpenBSD  TrustedBSD;
           security_focused_Linux   subtype:  Adamantix  Annvix  EnGarde_Secure_Linux  Fedora  Hardened_Gentoo
                                              Hardened_Linux  Immunix  Openwall_Linux  Red_Hat_Enterprise_Linux;
           security_focused_Solaris subtype:  Trusted_Solaris;  Security focused softwares

  >  security_focused_operating_system
     anti-virus_software  anti-spyware_software  anti-Spam_software
       subtype:  trusted_operating_system
                 {security_focused_BSD  security_focused_Linux  security_focused_Solaris},
       part:  trusted_operating_system__TOS,
     //enforcing: computer_security_policy

       url:; < computer_security_model (above);
  The name "object-capability model" is due to the idea that idealized object-based programming and capability-based programming are two ways of looking at the same thing. Under the object-capability paradigm: Objects are both accessed and designated through unforgeable references called capabilities (addresses). Objects interact by sending messages to these capabilities (addresses).
# A capability (address) can be obtained by: creation and receiving a message  Security threatening softwares

  subtype: software_virus  software_worm  trojan_horse_software;

       > resist#Virus;       //threat for information security in particular

3.  Situations: states or processes

  >  {security_related_state  security_related_process};

       >  #threat                         //  < (#warning < #human_action)
          #authentication                 //  < #action;
          #security_measures___security   //  < (#safeguard < (#decision < #action)) 
          #risk___peril___danger          //  < (#venture  < #task)

3.1.  States

  >  {#safety.state  #danger.state}   //two exclusive subtypes of #condition.state in WordNet
     #unity__integrity  //an indirect subtype of #unity is #privateness (a subtype of which is #confidentiality)
     #insecurity.feeling;  //indirect subtype of #feeling which is subtype of #state

/* Stated elsewhere: 

     #safety.state  (^the state of being safe; "the safety of the children"^)
       subtype:  #risklessness  #impregnability  #security;

         #security  subtype:  #public_security  #secureness;

   subtype:  #radioprotection;

     subtype:  #security.assets;

               #security.assets  subtype:  #hedging  #insurance;

                 #insurance  subtype:  #coinsurance  #reinsurance  #self-insurance  #health_insurance
                                       #fire_insurance  #life_insurance  #automobile_insurance;
     #danger.state  (^the condition of being susceptible to harm or injury^)
       exclusion:  #safety.state
       subtype:  #clear_and_present_danger  #hazardousness  #insecurity  #riskiness  #vulnerability.danger
                                            //#security and #insecurity are exclusive 

3.2.  Security threatening processes

3.3.  Managing

       supertype:  #management  pm#iterative_never-ending_process,
       subtype:  taking_one_or_several_security_measures

             (^the choice of countermeasures (controls) used to manage risks must strike a balance between productivity,
               cost, effectiveness of the countermeasure, and the value of the informational asset being protected^)
            supertype:  #security_measures, //indeed, despite the name, WordNet's "security_measures" refers to a process
            subtype: taking_one_or_several_information_security_measures;

            >  social_engineering;

               social_engineering (^The act of manipulating people into performing actions or divulging confidential
                                    information. While similar to a confidence trick or simple fraud, the term 
                                    typically applies to trickery for information gathering or computer system access
                                    and in most cases the attacker never comes face-to-face with the victim^)

            <  #engineering 
            subtask:  information_security   physical_security  process_of_the_economics_of_security,

              (^protecting information and information systems by detecting tampering and ensuring reliability,
                confidentiality, integrity, authentication, availability, and non-repudiation, whether the information
                are in storage, processing, or transit, and whether threatened by malice or accident.^)
            goal:  #information_risklessness,
            subtype:  information_security_management  information_security_evaluation
                      taking_one_or_several_information_security_measures  cryptographic_process 
                      supporting_the_security_of_a_particular_object,  //specialized for RFID objects in this other file
                        //the folowing types are specialized in the RESIST ontology
                      pm#Fault_Acceptance/Avoidance  resist#Threats-To-Dependable-And-Secure-Systems
                      resist#Dependability-And-Security-Provision  resist#Dependability-And-Security-Analysis
                      resist#Fault-Acceptance  resist#Fault-Avoidance     resist#System-Life-Cycle
            domain_object:  dependancy_or_information_security_attribute  security_threat_related_agent
                            security_related_state ...

                 subtype:  security_engineering  information_assurance  information_security  computer_security;
                           // supporting_business_continuity   disaster_recovery
                           // SEQUENCE{enumerating_and_classifying  risk_assessment  creating_a_risk_management_plan}

                      (^security risk management with an emphasis on strategic risk management over tools and tactics^)
                    subtask:  information_security  supporting_information_privacy   enforcing_rules_and_software_compliance
                    url: ;

                        (^compared to computer_security, information_security in general is less concerned with the
                          availability and correct operation of a 'computer system' and more concerned with the 
                          confidentiality, integrity and availability of data regardless of the form the 'data' may
                          take: electronic, print or other forms^)
                       subtask: computer_security,
                       url: ;

                        computer_security (^focuses on ensuring the availability and correct operation of a computer system
                                            without concern for the information stored or processed by the computer^)
                          object: secure_operating_systems,

3.4.  Evaluating

3.5.  Designing

3.5.1.  Applying design principles

  >  applying_the_principle_of_least_privilege

      descr:  principle_of_least_privilege ;

      parameter:  defense_in_depth_principle;

    breaking_the_system_up_into_smaller_components  < obtaining_clear_dependable_code 
        -> automated theorem proving to prove the correctness of crucial software subsystems
           rigorous use of code review and unit testing represent a best-effort approach to make modules secure.

      parameter:  fail_secure_principle;  technique in which a program is divided into parts which are limited to the specific privileges they require in order to perform a specific task.

    reacting to breaches




Information security must protect information throughout the life span of the information    Using a defence in depth strategy, should one defensive measure fail there are other defensive measures in place that continue to provide protection.

  Administrative controls___procedural controls (^approved written policies, procedures, standards and guidelines^)

  Logical controls (also called technical controls)  The principle of least privilege requires that an individual, program or system process is not granted any more access privileges than are necessary to perform the task

  Physical controls  Separation of duties ensures that an individual can not complete a critical task by himself. 

Additional insight into defence in depth can be gained by thinking of it as forming the layers of an onion, with data at the core of the onion, people as the outer layer of the onion, and network security, host-based security and applications security forming the inner layers of the onion.

    "Due care are steps that are taken to show that a company has taken responsibility for the activities that take place within the corporation and has taken the necessary steps to help protect the company, its resources, and employees." And, [Due diligence are the] "continual activities that make sure the protection mechanisms are continually maintained and operational."
To fully protect the information during its lifetime, each component of the information processing system must have its own protection mechanisms. The building up, layering on and overlapping of security measures is called defense in depth. 
Using a defence in depth strategy, should one defensive measure fail there are other defensive measures in place that continue to provide protection.
Within computer systems, the two fundamental means of enforcing privilege separation are access control lists (ACLs) and capabilities. The semantics of ACLs have been proven to be insecure in many situations (e.g., Confused deputy problem). It has also been shown that ACL's promise of giving access to an object to only one person can never be guaranteed in practice. Both of these problems are resolved by capabilities.  access control list (ACL) is a list of permissions attached to an object. The list specifies who or what is allowed to access the object and what operations are allowed to be performed on the object capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object. 

Capability-based security


   capability-based system permits the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system.

3.5.2.  Using cryptographic techniques

  >  digital_signature_management ;

information security uses cryptography to transform usable information into a form that renders it unusable by anyone other than an authorized user; this process is called encryption.

3.5.3.  Supporting authentication and access controls

    (^Controlling and selectively authorizing access of subjects to objects (^resources of network or resources contained in computer systems), for business intelligence purposes^)
    > {discretionary_access_control  mandatory_access_control  role-based_access_control} 
      {role-based_access_control  user-based_access_control},

    subtask: 1..* supporting_authentication (refikMolva),
               //any supporting_access_control has for subtask at least 1 supporting_authentication

          (^access rights of subjects to objects are under the control of each object owner^)

        mandatory_access_control___MAC  (^access rights are governed by global rules set by the security administrator^)
          > context-based_access_control,
//preventing loss of Possession or Control

            context-based_access_control  (^intelligently filters TCP and UDP packets based on application layer protocol session information and can be used for intranets, extranets and internets^)
              //subtask of :  preventing_Denial-of-Service ...  permitting_Real-time alerts and audit trails

         (^Traditional ACL systems assign permissions to individual users, which can become cumbersome in a system with a large number of users. In a more recent approach called role-based access control, permissions are assigned to roles, and users are assigned to roles^)
          > lattice-based_access_control,

        user-based_access_control___object-based_access_control (^role-based_access_control assigns permissions to specific operations with meaning in the organization, rather than to low level data objects^);
  The foundation on which access control mechanisms are built start with identification and authentication.

  Identification is an assertion of who someone is or what something is. If a person makes the statement "Hello, my name is John Doe." they are making a claim of who they are. However, their claim may or may not be true. Before John Doe can be granted access to protected information it will be necessary to verify that the person claiming to be John Doe really is John Doe.

  Authentication is the act of verifying a claim of identity. When John Doe goes into a bank to make a withdrawal, he tells the bank teller he is John Doe (a claim of identity). The bank teller asks to see a photo ID, so he hands the teller his driver's license. The bank teller checks the license to make sure it has John Doe printed on it and compares the photograph on the license against the person claiming to be John Doe. If the photo and name match the person, then the teller has authenticated that John Doe is who he claimed to b
There are three different types of information that can be used for authentication: something you know, something you have, or something you are. 
Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
 - Authentication and non-repudiation of the client/server, using digital signatures
 - Uses public keys for authentication, symmetric keys for session privacy
 - SSL breaks up, compresses, hashes, and encrypts data before sending it
 - SSL was designed to protect against man_in_the_middle_attack
    Web sites have digital certificates signed by a CA
    Clients can verify that they talk with the right server
 - SSL was designed to protect against replay attacks
     Traffic is encrypted with session keys, which depend on a one-time unique number (connection ID)

  After a person, program or computer has successfully been identified and authenticated then it must be determined what informational resources they are permitted to access and what actions they will be allowed to perform (run, view, create, delete, or change). This is called authorization. Authorization to access information and other computing services begins with administrative policies and procedures. The policies prescribe what information and computing services can be accessed, by whom, and under what conditions. The access control mechanisms are then configured to enforce these policies.
The non-discretionary approach consolidates all access control under a centralized administration. The access to information and other resources is usually based on the individuals function (role) in the organization or the tasks the individual must perform. The discretionary approach gives the creator or owner of the information resource the ability to control access to those resources. In the Mandatory access control approach, access is granted or denied bases upon the security classification assigned to the information resource.
Examples of common access control mechanisms in use today include Role-based access control available in many advanced Database Management Systems, simple file permissions provided in the UNIX and Windows operating systems, Group Policy Objects provided in Windows network systems, Kerberos, RADIUS, TACACS, and the simple access lists used in many firewalls and routers.
To be effective, policies and other security controls must be enforceable and upheld. Effective policies ensure that people are held accountable for their actions. All failed and successful authentication attempts must be logged, and all access to information must leave some type of audit trail.[citation needed]
The concept of type enforcement (TE) in the field of information technology is related to access control.
  Domain Type Enforcement-Language

     (^Ensuring that users or objects (like documents) are genuine, and hence, corroborating the identity of subjects for establishing relationships between the subjects of a system and the actual access requests. Examples of subtasks: (i) using a large size scalable authentication infrastructure, (ii) using cryptographic measures to prove its own identity (and function) to another process/entity, or (iii) asking another process/entity to prove its identity (and function) before giving it some information.^)
  >  {origin_authentication  peer_authentication},
  instrument:  digital_signature;

     origin_authentication (^identifying the sender of a message^);
     peer_authentication (^mutual authentication of communicating parties^);

3.6.  Satisfying criterias

  subtype:  {supporting_confidentiality 

3.6.1.  Supporting confidentiality or privacy

privacy: Refik: détourner aussi attaques légales (security: attaque illegales)
privacy: Slides: security about users' personal data (Personally Identifiable Information, PII)
  Several classes of privacy: Anonymity / pseudonymity, Unlinkability, Unobservability
  sol: Privacy on Server Side: Confidentiality, Access Control
       Anonymous/pseudonymous credentials 
       Enterprise Privacy Policies (P3P / ePal)Declare how personal data is going to be used
       Future: Support for automated user control of PII (Privacy-enabled Identity Management Systems)

process_supporting_the_confidentiality_of_information  (^information: stored/exchanged^)
  > {supporting_confidentiality  process_subtask_of_supporting_confidentiality};

      subtask:  process_subtask_of_supporting_confidentiality;

     (^Preventing the unauthorized disclosure of information.
       Examples of subtasks: (i) using a scalable confidential architecture where security policies are enforced,
       (ii) encrypting communication to prevent eavesdropping, (iii) identifying how information is encoded and
       implementing different protocols simultaneously,
       (iv) avoiding unauthorized people to look at your screen,
       (v) avoiding machines or disks to be physically stolen .^)
     > {supporting_data_confidentiality  supporting_traffic_confidentiality};

     subtask:  encrypting the card number during transmission,
               limiting the places where it might appear (in databases, log files, backups, printed receipts, and so on)
               restricting access to the places where it is stored. 

         (^protecting data carried over the network or stored in computers attached to the network^);

           (^protecting against the disclosure of traffic patterns/volumes and hence the inference of certain
             relationship between senders and receivers^);

     (^Supporting the privacy of an element's information for business integrity/intelligence purposes, for example by (i) disabling the element when it should not be used anymore, (ii) identifying or using the right password or shared secret for communications, (iii) securely storing secret information, (iv) supporting anonymous data transactions, and (v) preventing any user of the element to know about other uses of the element^);

Data confidentiality through the use of encryption

3.6.2.  Supporting integrity

    (^Preventing the unauthorized or accidental modification or deletion of information. Examples of subtasks: (i) preventing malicious writing, (ii) not keeping information longer that necessary, (iii) ensuring that information is consistent, accurate, up-to-date, adequate, relevant and not excessive, (iv) making information accessible to those who are entitled to know about it, (v) only allowing "expected uses" of the information^);
  subtask: prevent/correct mis-typing systems
  Business continuity planning
breach of utility  losing the decryption key

Data integrity through the use of message authentication codes

3.6.3.  Supporting accessibility and interoperability

Business Continuity is the mechanism by which an organization continues to operate its critical business units, during planned or unplanned disruptions that affect normal business operations, by invoking planned and managed procedures.

Change management is a formal process for directing and controlling alterations to the information processing environment.
The objective of Change Management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimize the number and impact of any related incidents upon service.

Disaster Recovery Planning is all about continuing an IT service.
Though DRP is part of the BCP process, DRP focusses on IT systems recovery and BCP on the entire business.
DRP is one of the recovery activities during execution of a Business Continuity Plan.

     (^Ensuring (for business integrity/intelligence/deployment purposes) that computing systems and the security controls used to protect the information are all available and functioning correctly when the information is needed; for example (i) ensuring that this element cannot be disabled when it should not, (ii) preventing monopolisations (e.g., Denial of Service attack), and (iii) being resilient (e.g., via back-ups facilities^);

     (^Supporting secure interoperability with secure and insecure entities or processes, for operational and deployment purposes, for example by (i) using temporary IDs, (ii) restricting accesses, (iii) applying specific reading policy, (iv) supporting existing standards and frameworks for identity and access control^);

3.6.4.  Supporting imputability

     (^ensuring that one party of a transaction cannot deny having received a transaction or that the other party cannot deny having sent a transaction; this implies asking for signed information and managing it^)
  > {supporting_the_non-repudiation_of_sent_information
  instrument:  digital_signature;