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.
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.
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 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
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;
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;
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:
Provision of user ID's and credentials to users.
Access Rights Control
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!
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.
In this video we take an overall view on the information security management process, linking Goals, Situational Awareness, Resources, Priotities and Plans, etc...
Conventional wisdom seems to assume that being intelligent is about having all the answers; but I beg to disagree. An intelligent manager is he who makes the right questions, as these will make evident what he knows and what we has to learn about the complex landscape of his company. The right questions will place a manager in the right track for a well thought security strategy.
My favourite set of questions, seasoned with my own answers, follows.
How do you know were you are? Perform assessments that compare your model of company with theoretical models, which can be standards or compliance requirements.
Where are you? This is answered by the assessments results, ranging from the result of a PenTest to finding you current O-ISM3 maturity.
How safe is the organisation? This depends on what are the security targets, how mature is the organisation's security management, and the context of the organisation. A risk assessment can give rough idea of where the organisation stands.
How capable is the organisation to remain safe? The higher O-ISM3 capability level achieved, the more capable it is.
Where would you like to be? An objective answer is to state explicitly your goals, among them: business goals, legal and standard compliance goals, and technical goals.
How close to your goal can you afford to be? Unless you organisation has unlimited resources, you can express this using security targets.
How much should be spent in security? The minimum to achieve security targets. There is normally no need to achieve invulnerability.
How can you get there? Get management commitment, procure resources, project the implementation of the security processes you can afford starting with knowledge management.
How do you stay there when you manage it? Take decisions to get closer to your security targets and use metrics to monitor your results.
How do you stay there when you get someone to manage it for you? Agree on metrics based SLAs with your providers and use them to monitor their results.
How do you improve you ISMS effectiveness and efficiency? Enhance the capability of your security processes using metrics, and control charts.
How good are you at staying there? Make an assessment of the capability of your security processes.
How do you prove to others were you are? Get your ISMS certified.
This video presents in an entertaining way the actual difference between using confidentiality, integrity, availablity in actual work scenarios versus using Security Quarks, I published a short piece on the same subject in SC Magazine