pm#process_supporting_the_security_of_some_RFID_related_entity_or_process
  supertype:  pm#process_supporting_the_security_of_a_particular_object
  subtype:  pm#process_supporting_the_security_of_some_RFID_element
     subtype:  pm#process_supporting_the_security_of_some_RFID_tag
        subtype:  bridge#process_supporting_authentication_in_some_RFID_tag__id_req_tag_1
           subtype:  bridge#process_permitting_an_RFID_tag_to_prove_its_identity_to_an_RFID_reader
           subtype:  bridge#process_permitting_an_RFID_tag_to_ask_its_identity_to_an_RFID_reader__TC2
           subtype:  bridge#process_preventing_an_RFID_tag_to_be_moved_to_another_product__TI3
           subtype:  bridge#process_ensuring_that_an_RFID_tag_has_only_one_EPC__TI4
           subtype:  bridge#process_verifying_an_RFID_tag_after_its_writing__TI5
           subtype:  bridge#process_authenticating_an_RFID_tag__TI6
           subtype:  bridge#process_preventing_an_RFID_tag_to_be_cloned__TI7
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_sent_by_some_RFID_tag__id_req_tag_5  A reader that includes signature functionality must request that a tag signs information sent to it. With the signature, a reader can prove that a specific tag has communicated with it.
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_tag__id_req_tag_7  Tag must be secured against malicious writing of EPC.
           subtype:  bridge#process_securing_an_RFID_tag_against_the_malicious_writing_of_its_EPC__TI2
           subtype:  bridge#process_protecting_an_RFID_tag_when_moving_from_closed_to_open_loop__TI8
           subtype:  bridge#process_protecting_an_RFID_tag_when_moving_from_open_to_closed_loop__TC4
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_between_RFID_tag_and_reader__id_req_tag_2  Communication between tag and reader must be encrypted for applications that need to prevent eavesdropping of the contact-less channel.
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_tag__id_req_tag_4
           subtype:  bridge#process_permitting_to_disable_an_RFID_tag_when_it_is_not_within_company-influence__TC1
              subtype:  bridge#process_permitting_to_disable_an_RFID_tag_when_it_is_sold_to_a_final_user__TC3
        subtype:  bridge#process_supporting_the_availability_of_access_to_information_in_some_RFID_tag__id_req_tag_3___TI1  Tags should not be disabled when product is being used by business process.
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_tag__id_req_tag_8  The tag must comply with EPC, maybe with temporary IDs, or restrict access to some protected memory only to authenticated readers. This allows to apply secure tags in standard supply chains but makes secure operation possible (e.g. after POS).
           subtype:  bridge#process_permitting_a_secure_RFID_tag_to_operate_with_existing_insecure_readers__TO1
     subtype:  pm#process_supporting_the_security_of_some_RFID_reader
        subtype:  bridge#process_supporting_authentication_in_some_RFID_reader__id_req_rea_1___RC3  Mechanisms must be in place for an RFID reader to authenticate its identity and function, to tags and network components
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_reader__id_req_rea_6  The reader must implement access control on any interfaces that allow the modification of reader operation or access to internal information.
           subtype:  bridge#process_forbidding_corrupted_or_fake_readers_to_access_internal_business__RC2
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_reader__id_req_rea_7___R12__r12  Injection of data from readers needs to be controlled in order to avoid the data corruption with false information.
           subtype:  bridge#process_permitting_RFID_reader_to_read_and_correctly_transmit_tag_information__RI3
           subtype:  bridge#process_protecting_companies_internal_systems_from_attacks_by_corrupted_malicious_or_fake_RFID_readers__RI1
           subtype:  bridge#process_preventing_an_RFID_reader_to_allow_injection_attacks_from_malicious_tag_data__RO3
           subtype:  bridge#process_preventing_a_compromised_RFID_reader_to_provide_means_to_attack_other_IT_systems__RO2
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_with_a_RFID_reader__id_req_rea_2
           subtype:  bridge#process_permitting_an_RFID_reader_to_identify_in_which_way_the_tag_information_is_encoded_and_to_implement_different_protocols_simultaneously__id_req_rea_2
           subtype:  bridge#process_forbidding_corrupted_readers_to_eavesdrop_on_tag_events__RC1
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_reader
           subtype:  bridge#identification_or_use_by_a_RFID_reader_of_the_right_password_or_shared_secret_for_communications__id_req_rea_4a  The reader must be able to identify which secret should be applied to encoded information. The right password or shared secret should be provided to the right reader with secure communication.
           subtype:  bridge#secure_storage_of_the_secret_information_by_a_RFID_reader__id_req_rea_4b  The secret information required to decode the tag must be maintained in a secure memory part of the reader. A secret can not be disclosed to the wrong application, user or reader owner.
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_reader
           subtype:  bridge#process_supporting_the_compliance_of_some_RFID_reader_with_some_reading_policy__id_req_rea_8a  It is mandatory to provide a mechanism to guarantee that the RFID reader complies with a specific reading policy in support of fair information practice principles.
           subtype:  bridge#process_permitting_a_secure_RFID_reader_to_operate_with_secure_and_insecure_RFID_tags__id_req_rea_8b___RO1  Secure reader should be able to operate with secure and insecure RFID tags.
     subtype:  pm#process_supporting_the_security_of_some_RFID_related_network
        subtype:  bridge#process_supporting_authentication_in_some_RFID_related_network__id_req_net_1  Mutual authentication between the parties which takes part in EPC data communication. A large size scalable authentication infrastructure must be used.
           subtype:  bridge#process_authenticating_network_transactions_in_some_RFID_related_network__N17
           subtype:  bridge#process_authenticating_client_queries_in_some_RFID_related_network__NC2
           subtype:  bridge#process_ensuring_that_the_origin_of_event_in_an_RFID_related_network_is_provable__NI3
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_in_some_RFID_related_network__id_req_net_5  Data contributions to the system must be signed in order that individual parties can me held accountable for the quality of the data they provide. There must be accountability for data validity (N19)
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_related_network__id_req_net_6  Information shares must own the capability to specify the conditions under which they want to share the data. These rules must be managed by sound access controls mechanism.
           subtype:  bridge#process_using_transport_security_to_complement_EPC_network_component_security__NI8___NC5
           subtype:  bridge#process_securing_event_collection_in_some_RFID_related_network__NC1
           subtype:  bridge#process_allowing_companies_to_choose_who_to_trust_with_hosted_data_in_some_RFID_related_network__NC3
           subtype:  bridge#process_allowing_companies_to_have_withdrawal_and_access_control_over_their_hosted_data_in_some_RFID_related_network__NC4
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_related_network
           subtype:  bridge#process_supporting_only_authorized_and_accurate_registration_of_EPC_ISs_in_a_DS__id_req_net_7a  Only authorized parties must be allowed to register their EPC ISs with a DS in such a way that parties can not be injected selfishly and inaccurate information into the system.
           subtype:  bridge#process_supporting_the_visibility_and_up-to_date_nature_of_information_in_some_RFID_related_network__id_req_net_7b  A client's access rights must be able to access 'all' the data she is entitled to. In order to prevent from data inconsistency the information must be up-to-date.
           subtype:  bridge#process_and__RFID_infrastructure_allowing_effective_anti-counterfeiting_through_multiparty_track_and_trace_information___NI2
           subtype:  bridge#process_allowing_only_secure_updates_to_prevent_data_corruption_in_RFID_related_network__NI4
           subtype:  bridge#process_making_trusted_parties_validate_received_data_in_RFID_related_network__NI5
           subtype:  bridge#process_ensuring_that_network_transactions_are_well_formed__NI6
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_in_a_RFID_related_network__id_req_net_2  A scalable confidential architecture must be used. The external transaction through the interfaces among discovery services and other parties, i.e., queries and updates must be confidential with accordance to the security polices which should set the fields of the DS record to be protected.
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_related_network
           subtype:  bridge#process_supporting_anonymous_data_transactions_in_some_RFID_related_network__id_req_net_4  A party should not have to to disclose its real identity. The EPC network elements must implement access control and authentication mechanism by which anonymous data transactions can be feasible.
        subtype:  bridge#process_supporting_the_availability_of_some_RFID_related_network__id_req_net_3___NI1___NO1  EPICS systems must be resilient to Internet/local (Distributed) Denial of Service attack or failure of components, and provide back-ups facilities in order to avoid unavailability at any time.
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_related_network__id_req_net_8___NO2  Network components should be built upon existing standards and frameworks for identity and access control.
     subtype:  pm#process_supporting_the_security_of_some_RFID_related_application
        subtype:  bridge#process_supporting_authentication_in_some_RFID_related_application__id_req_app_1  Users must own a single credential and must authenticate to the application to which want to get access.
           subtype:  bridge#process_detecting_a_RFID_tag_movement_between_products__AI2
           subtype:  bridge#process_detecting_a_RFID_cloned_tag__AI3
           subtype:  bridge#process_supporting_authentication_between_partners_before_a_RFID_related_communication_between_companies__AI4___AC1
           subtype:  bridge#process_allowing_a_company_to_track_and_trace_an_RFID_related_product_in_order_to_verify_its_authenticity__AI5
           subtype:  bridge#process_or_architecture_ensuring_that_RFID_related_changes_and_access_can_be_traced_back_to_specific_identities__AI6
           subtype:  bridge#process_recording_EPCs_in_business_transactions__AI7
           subtype:  bridge#process_supporting_the_validation_and_audit_of_business_transactions__AI8
           subtype:  bridge#process_ensuring_that_data_is_transferred_only_with_clear_destination_and_usage__AC2
           subtype:  pm#process_ensuring_that_a_RFID_tag_is_destroyed_when_it_is_disposed_of
           subtype:  pm#process_hiding_the_way_RFID_tag_identifiers_are_generated_in_a_company
           subtype:  pm#process_allowing_to_delete_all_information_related_to_a_tag_when_a_tag_is_killed
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_sent_or_received_by_some_RFID_related_application__id_req_app_5  The parties which update DS records must be accountable for this fact. Likewise, the responsibility which the parties own in order not to refuse having receive queries at any time.
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_related_application__id_req_app_6  Employee and application user must own an access rights depending on the roles assigned by the valid authority in charge of the EPC application.
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_related_application__id_req_app_7  privacy concerns of companies and customer must be achieved by assuring the integrity of the relevant data collected. To facilitate a bridge#process_supporting_the_availability_of_some_RFID_related_application, the collected data must fulfill the following features: 1) data collected should be adequate, relevant, and not excessive, 2) data should not be kept longer that necessary, 3) companies and customers have the right to know data about them or their products is stored, 4) data collected should be processed for a specific purpose (e.g. data mining to infer new, unauthorized data shouldn't be permitted or feasible.
           subtype:  bridge#process_verifying_RFID_related_product_characteristics__AI1
           subtype:  bridge#process_guaranteing_the_completeness_of_records__AI9
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_between_RFID_related_application_and_network_service__id_req_app_2  interfaces should assure confidentiality in the exchange data between the applications and the network services.
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_related_application__id_req_app_4
           subtype:  bridge#process_preventing_anyone_to_know_if_another_use_of_some_RFID_discovery_service_is_made  The parties interacting with DS should not be able to see from the usage of DS whether or not another party is querying or updating the DS.
        subtype:  bridge#process_supporting_the_availability_of_some_RFID_related_application__id_req_app_3  DS must be able to provide mechanism whereby prevent users from monopolising the resources.
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_related_application__id_req_app_8  Even though any new security mechanisms and trust models affect the in place mechanisms and the current applications and in order to avoid high cost application migration, the interoperability should not only considered at intra-organizational level.
  subtype:  pm#process_supporting_some_security_attribute_in_some_RFID_related_entity_or_process
     subtype:  pm#process_supporting_authentication_in_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_authentication_in_some_RFID_tag__id_req_tag_1
        subtype:  bridge#process_supporting_authentication_in_some_RFID_reader__id_req_rea_1___RC3  Mechanisms must be in place for an RFID reader to authenticate its identity and function, to tags and network components
        subtype:  bridge#process_supporting_authentication_in_some_RFID_related_network__id_req_net_1  Mutual authentication between the parties which takes part in EPC data communication. A large size scalable authentication infrastructure must be used.
        subtype:  bridge#process_supporting_authentication_in_some_RFID_related_application__id_req_app_1  Users must own a single credential and must authenticate to the application to which want to get access.
     subtype:  pm#process_supporting_the_non-repudiation_of_information_sent_or_received_by_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_sent_by_some_RFID_tag__id_req_tag_5  A reader that includes signature functionality must request that a tag signs information sent to it. With the signature, a reader can prove that a specific tag has communicated with it.
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_in_some_RFID_related_network__id_req_net_5  Data contributions to the system must be signed in order that individual parties can me held accountable for the quality of the data they provide. There must be accountability for data validity (N19)
        subtype:  bridge#process_supporting_the_non-repudiation_of_information_sent_or_received_by_some_RFID_related_application__id_req_app_5  The parties which update DS records must be accountable for this fact. Likewise, the responsibility which the parties own in order not to refuse having receive queries at any time.
     subtype:  pm#process_supporting_the_access_control_of_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_reader__id_req_rea_6  The reader must implement access control on any interfaces that allow the modification of reader operation or access to internal information.
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_related_network__id_req_net_6  Information shares must own the capability to specify the conditions under which they want to share the data. These rules must be managed by sound access controls mechanism.
        subtype:  bridge#process_supporting_the_access_control_of_some_RFID_related_application__id_req_app_6  Employee and application user must own an access rights depending on the roles assigned by the valid authority in charge of the EPC application.
     subtype:  pm#process_supporting_the_integrity_of_information_in/from_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_tag__id_req_tag_7  Tag must be secured against malicious writing of EPC.
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_reader__id_req_rea_7___R12__r12  Injection of data from readers needs to be controlled in order to avoid the data corruption with false information.
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_related_network_tag
        subtype:  bridge#process_supporting_the_integrity_of_information_in/from_some_RFID_related_application__id_req_app_7  privacy concerns of companies and customer must be achieved by assuring the integrity of the relevant data collected. To facilitate a bridge#process_supporting_the_availability_of_some_RFID_related_application, the collected data must fulfill the following features: 1) data collected should be adequate, relevant, and not excessive, 2) data should not be kept longer that necessary, 3) companies and customers have the right to know data about them or their products is stored, 4) data collected should be processed for a specific purpose (e.g. data mining to infer new, unauthorized data shouldn't be permitted or feasible.
     subtype:  pm#process_supporting_the_confidentiality_of_communication_with_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_between_RFID_tag_and_reader__id_req_tag_2  Communication between tag and reader must be encrypted for applications that need to prevent eavesdropping of the contact-less channel.
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_with_a_RFID_reader__id_req_rea_2
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_in_a_RFID_related_network__id_req_net_2  A scalable confidential architecture must be used. The external transaction through the interfaces among discovery services and other parties, i.e., queries and updates must be confidential with accordance to the security polices which should set the fields of the DS record to be protected.
        subtype:  bridge#process_supporting_the_confidentiality_of_communication_between_RFID_related_application_and_network_service__id_req_app_2  interfaces should assure confidentiality in the exchange data between the applications and the network services.
     subtype:  pm#process_supporting_the_privacy_of_information_in_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_tag__id_req_tag_4
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_reader
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_related_network
        subtype:  bridge#process_supporting_the_privacy_of_information_in_some_RFID_related_application__id_req_app_4
     subtype:  pm#process_supporting_the_availability_of_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_the_availability_of_access_to_information_in_some_RFID_tag__id_req_tag_3___TI1  Tags should not be disabled when product is being used by business process.
        subtype:  bridge#process_supporting_the_availability_of_some_RFID_related_network__id_req_net_3___NI1___NO1  EPICS systems must be resilient to Internet/local (Distributed) Denial of Service attack or failure of components, and provide back-ups facilities in order to avoid unavailability at any time.
        subtype:  bridge#process_supporting_the_availability_of_some_RFID_related_application__id_req_app_3  DS must be able to provide mechanism whereby prevent users from monopolising the resources.
     subtype:  pm#process_supporting_interoperability_from/to_some_RFID_related_entity_or_process
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_tag__id_req_tag_8  The tag must comply with EPC, maybe with temporary IDs, or restrict access to some protected memory only to authenticated readers. This allows to apply secure tags in standard supply chains but makes secure operation possible (e.g. after POS).
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_reader
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_related_network_tag
        subtype:  bridge#process_supporting_interoperability_from/to_some_RFID_related_application__id_req_app_8  Even though any new security mechanisms and trust models affect the in place mechanisms and the current applications and in order to avoid high cost application migration, the interoperability should not only considered at intra-organizational level.

No statement uses or specializes pm#process_supporting_the_security_of_some_RFID_related_entity_or_process; click here to add one.

125 categories printed


Another search (with same display options)?