Anonymous architectures

Anonymous architectures

The verifiers of certified property statements in many cases do not require them

Identities for their activity. Thus, property statements can be anonymized by replacing the subject principal with a pseudonym with appropriate properties. The German Signature Law already provides for such certification (§ 7 para. 1-3 SigG) [8]. Accordingly, it is not necessary at the zoo cashier, for example, to learn the name of the student. It is only important that the property of students is attached to the person who submits a valid student ID and that it has been issued by a trustworthy agent. Thus, the student card could be interpreted anonymously by the Matrikelr. In the subject component instead of the name. of the student.

On the one hand, in the interest of attributability, the agent is additionally responsible to the users of the property statement for the purpose of disclosing pseudonyms by means of the assignment rule for specific purposes in relation to specific entities. On the other hand, in the interest of anonymity, the agent is responsible to the subjects for protecting the assignment rule and to respecting the policy known to the subject with regard to the discoverability and concatenation of the pseudonyms.

The following section 2 introduces architectures that provide user anonymity to the security administrators of a service, which can make observations based solely on the audit data provided by the service (see Figure 2).

The audit data are collected by the audit component of the service and made available to the audit analysis of the security administrators of the service (E1).

This generates according to the analysis purpose individual reports and sends them to the response unit (E2), which in turn reacts appropriately to the individual reports, e.g. by informing the Security Administra- tor and submitting proposals for action to him. A concrete instance of this scenario would be an intrusion-detection system whose analysis purpose is the discovery of known protection target violations caused by the service user.

Fig. 2-5 show the model of Fig. 1 corresponding anonymous Versio¬

in which an entity establishes anonymity of the service users towards the security administrators by first introducing a user pseudonym.

Since mutual interests of multiple entities are to be taken into account in multi-sided secure versions, this leads to the exclusion of the control of precisely these entities over the objects of interest, ie the pseudonyms in the property statements. Accordingly, for multilateral security, the assignment rule of agents to be trusted by the stakeholders must be controlled. This situation is shown in Fig. 3-5.

Fig. 6 shows, using the example of a service with a pseudonymizer, how the use of the technical purpose limitation for the orderly detectability simplifies the necessary control conditions. In the case of the technical purpose of discoverability, the pseudonyms are accompanied by the purpose-protected assignment rule (E2 below) so that it no longer has to be transmitted directly to the reidentifier (R1 above). The re-identification is as inevitably possible only in accordance with the purpose of orderly discovery [1]. Accordingly, the user no longer has to trust the entity that controls the reidentification.

When implementing anonymous audits, the timely pseudonym detectability and practicability, i. the independence of users and elaborate infra structures, of crucial importance. An analysis of the architectures has shown that these requirements can only be met jointly at the service level, ie in the subsequent anonymization of audit data. The following sections give examples of such solutions and the requirements to be met by the solutions.


With the partially implemented research system Intrusion Detection and Avoidance (IDA), the concept of intrusion detection analysis was introduced to anonymous audit data [9]. The implied research system Adaptive Intrusion Detection (AID) takes up this concept, which was introduced by IDA, whereby the architectures of AID and IDA differ greatly from one another [10]. Lundins firewall and the light gray frames for the interest of the security administrators to imputability. Dark filled boxes together realize multi-sided security. They are currently in the double-framed areas, that is, where conflicting interests are enforced.

Steps to simplify audits, document compliance, and mitigate risk

Most compliance violations are attributed to employees in trusts. In response, regulators and industry associations around the world have responded with appropriate anti-corporate crime rules and regulations to protect public and private interests. However, many companies generate a massive volume of data on their networks every day. Therefore, it seems almost impossible to track all user activity and detect abusive, unlawful or erroneous actions.

The good news is that there is a technology that can handle these challenges: Attachmate® Luminet® enterprise fraud management software. This technology helps companies collect the data they need to simplify the audit process, document compliance, and mitigate risk.

Who did what, when and why?

Continuous monitoring is essential to know exactly who did what and when, and then to put that information in the right context. Attachmate Luminet systematically breaks down this process into three steps:

Step 1: Collect data

Luminet captures and documents all user activity in all enterprise applications in real time – including every window and key press – and creates a complete and accurate audit trail directly from the network. This audit trail includes all updates and reads by regular and privileged users. The information is stored in a secure, digitally-signed repository and can be visually replayed to document the dialog boxes, key sequences, and activities for auditing.

Step 2: Analyze data

Luminet’s powerful analytics engine tracks users’ behavior patterns in real time, identifies overlapping patterns, and visually depicts activities and relationships. For example, does an accounting clerk notice that he or she is responsible for unusual payment transactions with a particular vendor? Or does an employee access the file of a specific person much more frequently than other employees with comparable tasks? Based on previously defined rules and weighted by threat, Luminet identifies suspicious behavior patterns and generates real-time alerts. In addition, these rules can be used to document existing control mechanisms for detecting irregular behavior.

Step 3: Create custom reports

Auditors expect accurate and detailed information about how thousands of users across the enterprise access sensitive information in hundreds of applications every day. But that’s not all: auditors expect this information to be available in a format that meets the respective regulatory requirements. Luminet provides access to dedicated audit information at all times – as well as coordinating reports to auditors’ needs. The manual removal of additional or other data from the log files is eliminated. Furthermore, auditors need not speculate on what might have happened because the log files do not provide satisfactory information.

With these three steps, Luminet provides the information organizations need to take informed action to simplify audits, document compliance, and mitigate risk.

Suppose you were able to …

• … merge the data from multiple systems into multiple departments to create a complete audit trail.

• … perform historical queries, pattern analysis, and behavior analysis against user activity to view key sequences in context.

• … to test the compliance before an external audit.

• Responding to changing editions by changing a few rules instead of having to completely change the log files.

• Provide clear and substantiated evidence – even long after the user activity in question.

With Luminet this is possible: without the installation of further controls or any changes to the program code.