Information System Models

There are two reasons for using a information system model in Information Security. The first is that in order to understand the threats faced by information systems, we need to understand their components, what is their behaviour and how they relate to each other. The second is that security policies are too often tied too closely to actual hardware and software components and rendered obsolete by technological advances. Using a good model of an information system provides a necessary layer of abstraction that can help to make security policies mode durable.

There are quite a few Turing-complete computer models, among them:

A Turing machine has the following components:

  • Tape: It stores information.

  • Head: It read or writes information.

  • Table: It specifies what will be the next action of the machine depending on the State and the current value under the Head.

  • State register

Nowadays, most computers follow the Von Neumann Architecture. Operating systems that run on Von Neumann machines often follow the Unix convention, where the information system components are:

  • File. This is equivalent to the “Tape”.

  • Process. This is equivalent to the “State register”, the “Table”, and the “Head”.

As early information systems where not networked, the components needed for inter-system communication where not modelled. As a matter of fact, operating systems like Inferno try to keep the file/process model alive.

O-ISM3 represents information systems using a reduced set of components, but a set complex enough to illustrate how networked information system behave.

  • Repositories: Any temporary or permanent storage of information, including RAM, databases, file systems, and any kind of portable media;
  • Interfaces: Any input/output device, such as screens, printers and fax;
  • Channels: Physical or logical pathways for the flow of messages, including buses, LAN networks, etc. A Network is a dynamic set of channels;
  • Borders define the limits of the system.
  • Services. Any value provider in an information system, including services provided by BIOS, operating systems and applications. A service can collaborate with other services or lower level services to complete a task that provides value, like accessing information from a repository;
  • Sessions. A temporary relationship of trust between services. The establishment of this relationship can require the exchange of Credentials.
  • Messages. Any meaningful information exchanged between two services or a user and an interface.

If you liked this article, consider taking advanced ISMS training online via Udemy

Beyond Authentication, Authorization and Accounting

Resources are precious

A very common oversimplification of access control is: "authentication, authorization and accounting". This narrow view obscures many subtle aspects of corporate practices for providing fine grained access to information resources.

Information systems represent users using user accounts or certificates and implement digital equivalents to guarded doors, records and signatures. While user accounts sometimes represent services or information systems instead of people, I will use the term "user" alone for simplicity.

Authentication is seen as a way to check for a users identity, but real implementations do not guarantee this. Every user account has an associated credential that is presented and validated by the system that controls the access to resources before the user of the user account can access those resources (this is called "login"). Upon login, we can't assert the identity of the user, or even if the user account's owner is the current user of the user account. What we do know is that someone who knows the user ID of a valid user account has presented to the system both the user ID and the associated credentials.

When we need to link user accounts and certificates to identifiable users, making users accountable for the use of the user account, we have to complement technical authentication with other controls.

The first control is checking the actual identity of the user before providing him with the set of user ID and credential. In countries were national ID cards exist, this control can be pretty straightforward. In other countries, widely different methods are used, normally checking if the user has information, papers and cards that only the legitimate user should have. I call this control User Registration.

The second control is preventing the user from sharing the credentials with other users. This can be achieved by using multiple credentials (biometric and password, for example)  Other enforcement controls are not as effective; for example one can warn the user of the consequences of sharing  the user ID and credential, and find ways to detect when this happens.

When protecting the anonymity of users is more important than making them accountable, we often need to guarantee that user accounts and certificates are not linked to identifiable users. This does not  mean that anonymous User Registration is trivial, as we often will want the users to fulfill certain criteria, what I call  Personality of the user. Common examples of personality test are: "Are you over 18?", "Do you live in Europe?", or "Are you human?". Anonymous user accounts are not intended to check who the user is, but to check if the user is the same who used the user account the last time it logged in.

It is not rare to find online applications that don't use use accounts at all, checking only for the personality of the user before providing access.

An additional aspect of authentication is session control, which limits:

  • The number of login attempts with an invalid credential or user ID; what happens after the limit is reached; the time lapse between login attempts.
  • The number of simultaneous sessions with the same user ID;
  • The longest duration of a session.

So under the umbrella of "Authentication", we find:

  • Validation for the actual identity of identified users OR validation of the Personality of anonymous users (User Registration)
  • Provision of user ID's and credentials to users.
  • Validation of the matching between user ID and credentials before grating any access to a resource.
  • Limits on the usage of the system with a user ID, with or without a matching credential (Session Control)

"Authentication" therefore has three component proofs, which are mixed and matched as needed:

  • Proof of identity.
  • Proof of personality.
  • Proof of ownership of the user account or digital certificate.

The traditional list of types of proof of ownership of the user account is:

  • Something you know (passwords)
  • Something you have (tokens and private keys)
  • Something you are (biometrics)

This list is not complete, we can include:

  • Something you like. What if we could test the taste for colors or music of a user, and reliably check it when the user wants to login?
  • Something you can do. What if we could test the some ability of a user, like typing patterns, and reliably check it when the user wants to login?
  • Something you think.  What if we could test the scale of values of a user, and reliably check it when the user wants to login? (I know, is far-fetched)

Authorization is seen as granting the use of resources to authorized users and deny it to unauthorized users. But, How does a user becomes authorized to use a resource?. A very simple scenario is when there is a Resource Owner, an Administrator, who manages the system, and a User. The user sends an "access rights request" to the resource owner, who can grant the request,  and ask the administrator to technically grant those rights on the resource to the user's user ID. At a later time, the authorized user can use his user ID and credential to authenticate to the system, and use the resource using the rights he has been granted.

So under the umbrella of "Authorization" we find:

  • Access Rigths Control
  • Authorization

Under the traditional Accounting concept of access control there are two distinct processes, Recording and Signing.

Recording registers accurately the results of access to resources, so these can be investigated and will and intent or responsibilities determined. The recording process will normally have to meet objectives for accuracy, including date and time. Recording normally registers;

  • Interface ID and Location;
  • User account or certificate ID;
  • Signature;
  • Type of Access Attempt (login, logout, change password, change configuration, connect/disconnect systems, repositories I/O interfaces, enabling/disabling admin access or logging, etc)
  • Date and Time of Access attempt;
  • Access attempt result;
  • Resource accessed.

Signing records the will and intent about a "document" (or a mail, video, song, photo, etc) of the owner of the user account or certificate concerning a document, such as agreeing, witnessing or claiming authorship of documents like original works, votes, contracts and agreements. Digital signatures are a special kind of record.

A digital signature using public key encryption allows for authentication of documents, but what does a digital signature actually authenticate?. You can assert third parties authorship sometimes. For example "I know that this was written by Abel because it is signed with his private key, no one contests his authorship, and Abel doesn't claim that his private key has been stolen".

But what you can't do is to assert your own authorship. Why? Because you can get a message from Abel, remove the digital signature and add your own, asserting that you are the author.

This is the reason why signing contracts can potentially become complicated. I could send you a signed contract, which you sign and send back for me to sign, which I could again sign to show I agree with your signing it, and send it to you so you can prove that I am committed to the contract, as the first signature only shows agreement to my own writing.

Summarizing, "Authentication, Authorization and Accounting" is an oversimplification for:

  • User Registration.
  • Provision of user ID's and credentials to users.
  • Authentication.
  • Session Control
  • Access Rights Control
  • Authorization
  • Recording
  • Signing

I hope UPASAARS doesn't become a popular looks ugly, doesn't it?

A final word on the equivalence between user accounts and digital certificates. A digital certificate serves the same purpose a user account does; providing and denying access to resources to people depending on what we know about them and how much we trust them.

For user accounts:

  • User Registration, provision of user ID's and credentials to users is performed in house.
  • The user account has a user ID and a credential or set of credentials.
  • Session Control is configured normally system by system.
  • Access Rights are granted or denied depending on the users identity and personality.

For digital certificates:

  • User Registration, provision of user ID's and credentials to users is performed by a certification authority.
  • The digital certificate has a Distinguished Name (equivalent to the user ID), and a credential (public key signed by a certification authority+private key) , which is a credential of the type "something you have".
  • Session Control is still configured system by system.
  • Access Rights are granted or denied depending on how much we trust the guarantees the certification authority provides about the users identity and personality.

The advantage of digital certificates over user accounts is that they scale; we can trust users that haven't gone through our own User Registration,  the disadvantage is that we can trust them only as much as we trust their Certification Authority regarding their User Registration quality in terms of how do they check their users identity and personality.

This is what OpenID ultimately tries to accomplish, without relying solely on digital certificates.

Bonus: Check these Identity Management videos from The Open Group!

If you liked this article, consider taking advanced ISMS training online via Udemy

What is O-ISM3 good for?

Reach new heights

There are several ways to use O-ISM3:

  • For someone who is using ISO9001: Build your ISMS using ISO9001 principles and infrastructure you already have and understand;
  • For someone who has no IS Management System: Build your ISMS in stages around your Business Goals, not some external or artificial goals;
  • For someone who wants to outsource security processes: Find out exactly what to outsource, who to link it to internal processes and how to create SLAs;
  • For someone who want to show commitment with security: Get a meaningful certificate that is not only compliant but useful (further business goals);
  • For someone who is already spending loads in IS: Use Security Targets and learn at least if the IS management system is working, or use Metrics and manage your IS management system with or without Auditors around you;
  • For someone who is experiencing pains using other approaches: Suit you processes to your needs in an environment by environment basis. Stop using Production Environment requirement for your Development Environment;
  • For a CISO: Get to tell Top Management, Middle Management and Administrators what are their responsibilities on security, in a more specific way than "Security is everyone's responsibility";
  • For businesses that are going out to tender for their services; For businesses that require a consistent approach by all service providers in a supply chain;
  • For  service providers to benchmark their IT service management; As the basis for an independent assessment;
  • For an organisation which needs to demonstrate the ability to provide services that meet customer requirements;
  • For  organizations which aims to improve service through the effective application of processes to monitor and improve service quality.

If you liked this article, consider taking advanced ISMS training online via Udemy