Compliance vs Continuous Improvement

In this video the pros and cons of the Compliance approach and the Continuous Improvement approach are weighed.

Most ISMS standards emphasise Risk Assessment and Audit. These management practices leave other information security management practices in shadows, which is specially unfair if you consider the limitations risk assessments face. Creating a risk assessment method is very easy, as you can make many choices:

  • The scope (what's in, what's out)
  • The depth (think OSI levels and above to business processes)
  • The way you model the parts/objects of the organisation, their relationships, and the states of their life cycles.
  • Your threat taxonomy (there is not a single one widely accepted one at all depth levels)
  • The way you score the impact on assets (dollars, high-medium-low or 1-5 Confidentiality, Integrity, Availability scales and expansions or combinations thereof)
  • Controls taxonomy (there is not a single one widely accepted one at all detail levels. Many use the ISO27001 list)
  • How you combine threats, their probability, controls, their quality and impact to reach a Risk figure.

The multiplicity of risk assessment methods and standards  makes exceedingly difficult to reuse or compare risk assessments, problem compounded with changes in the method design or even the way it is used. Very seldomly it is possible to compare this year's RA with the last years one, and comparing RA from different companies becomes an unattainable Saint Grail. A good risk assessment standard should meet the following criteria:

  • Reproducible. This means two different independent practitioners should get virtually the same work products and results.
  • Productivity (Added value) This means the work products should serve as inputs for:
  • Gauge how safe is the organisation;
  • Identify threats and weaknesses;
  • Choosing what processes are appropriate for fulfilling the security objectives;
  • Prioritising investment in security processes;
  • Quantifying investment in security processes.
  • Cost-effectiveness. Setting up a ISM system should be cheaper than operating it, just like the cost of choosing a security tool should be small in comparison with the cost of purchasing and using the tool.
  • Added value. This means the result of the process selection should be learnt from the process selection itself. If the process selection result is known beforehand, and the process selection is just a justification for a previously taken decision, the added value is nil,which negates any cost-effectiveness.

O-ISM3 considers  the following management activities:

  • Risk Assessment (part of GP-3) - Considers assets, threats, vulnerabilities, impacts to get a picture of security and prioritise design and improvements.
  • Audit. Using the GP-2 ISM System and Business Audit process, checks are made on whether the process inputs, activities and results match their documentation.
  • Certify: Certification it evaluates whether process documentation, inputs, outputs and activities comply with a pre-defined standard, law or regulation. The certificate provides independent proof of compliance that third parties can trust. This practice is also performed using GP-2 ISM System and Business Audit.

Additionally, and in equal footing:

  • Testing. Assessment of whether process outputs are as expected when test data is input. This is an aspect of TSP-4 Service Level Management.
  • Monitoring. Checking whether the outputs of the process and the resources used are within normal range for the purpose of detecting significant anomalies. This is also performed using TSP-4 Service Level Management.
  • Improving. Making changes in the process to make it better fit for the purpose, or to lead to a saving in resources. The removal of faults before they produce incidents, bottlenecks that hamper performance and making trade-offs are examples of process improvements.. This management practice needs information gained from evaluating, testing or monitoring the process. The gains from the changes (if any) can be diagnosed with subsequent testing, monitoring or evaluation. GP-3 ISM Design and Evolution provides a framework for monitoring.
  • Planning. Organising and forecasting the amount, assignment and milestones of tasks, resources, budget, deliverables and performance of a process. This is performed using TSP-4 Service Level Management.
    Evaluation. Required periodically to assess the outcomes of the ISM system.
  • Assessment. Using the GP-3 ISM Design and Evolution process, the following areas are assessed:
  • How well the process matches the organisation's needs and compliance goals expressed as security objectives.
  • How changes in the environment or management decisions in a process change the quality, performance and use of resources of the process;
  • Whether bottlenecks or single points of failure exist;
  • Points of diminishing returns;
  • Bench marking of processes between instances and other organisations.
  • Trends in quality, performance and efficiency.
  • Benefits realisation. Shows how achieving security objectives contributes to achieving business objectives, measures the value of the process for the organisation, or justifies the use of resources. This is performed using TSP-4 Service Level Management

So, do Audit, and assess your risks, but don't let this drain all you energy from real management.

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.

Beyond Authentication, Authorization and Accounting

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 acronym...it 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!

Pages