Zygma's Advanced Internal Management System (AIMS) is a simple documentation aid - simple yet extremely powerful.
AIMS is designed to address every single requirement in (hereafter simply 27001).
Desktop audits that have been performed using AIMS are testimony to the success of its design. Zygma's own ISMS is built on AIMS.
AIMS is an HTML document and is therefore read using a browser and modified using an HTML editor. The design uses a simple frames layout, with a navigation bar to the left, a banner frame, the main window and importantly, there are parts for the organization to complete. Nevertheless, the ISMS structure and standard text are already present.
Whereas many tools consist of checklists, AIMS actually gives organizations an applied ISMS skeleton with processes and procedures for operating and managing their information security, relieving them of the burden of interpreting the ISMS standard in terms of "how do I do this", and letting them focus on "how do I reflect my business in the ISMS".
The following text assumes you are familiar with ISMS terminology - if not refer to our and pages, and read the 'Terms and definitions' section in the actual 27001 standard.
S Pages associated with the whole of the PDCA cycle;
S A built-in facility for document control, which is a particular requirement of 27001 (and indeed ISO 9001).
This operates at three hierarchical levels of the ISMS, allowing for internal revisions to be managed prior to formal release
for operation. It provides for an amendment record capturing the incremental changes between versions, hyper-linked to the actual revised pages (or any other documents the owner chooses);
S Space to define the scope of the ISMS and the information/business context in which it is used;
S A built-in, near completed, prototype ISMS policy that covers all the requirements of 27001. All that needs to be done to complete it is to define the Information Security Forum (ISF), agree its terms of reference and confirm (or amend accordingly) the detailed wording of the policy statements. It should be noted that some of these policy statements are used to simplify the Statement of Applicability (SoA) which 27001 requires, and the two are hyperlinked together;
S Provision for carrying out the risk assessment and producing the risk treatment plans (RTPs) in accordance with our particular approach (see below). There are eight standard RTPs, which are built into AIMS, and a provision for the user to add others. To assist in achieving compliance, there are ready-made asset, threat and impact lists. Vulnerabilities are addressed during the process of fleshing out the RTPs;
S A substantially complete SoA, which is backwards linked to relevant policy statements and
the standard risk assessment events. Each of the 133 controls in the 27001 SoA are also linked to
five skeleton handbooks/manuals (staff handbook, managers' handbook, operations manual, IT development manual and business continuity plan) as appropriate. These skeleton handbooks/manuals provide a head start in producing the necessary procedures. If the procedures already exist, just copy them in or hyper-link to them. To complete the SoA, all that needs to be done is to link the controls to any user defined RTPs and mark as non-applicable those 27001 controls, which are not going to be implemented based on management decisions following from the results of the risk assessment;
S A facility for inclusion of the organization's training and awareness program;
S A built-in internal ISMS audit proforma and checklist, which ensures compliance of internal ISMS audits to the requirements of 27001. The internal audit procedure is defined and there is ready-made schedule;
S A built-in management system review checklist for use by the meeting secretary. Completion of the checklist will ensure that all inputs, discussion topics and outputs, required by 27001 are addressed at the meeting. The management review procedure is defined and there is a ready-made schedule. Built-in processes address requirements for corrective/preventive action and improvement - these are especially significant in terms of SOX compliance, e.g.;
S A to-do list and associated procedures;
S A compliance index, which takes every requirement in 27001 and hyperlinks it to the primary page which addresses that requirement.
Risk treatment plans:
Our risk assessment approach starts with the events and the impacts.
An event is something that causes an impact. In business terms, the impacts that seem to capture the
interest of senior executives include:
S Adverse press coverage;
S Customer dissatisfaction;
S Inability to carry out some or all of the organization's business;
S Loss of revenue;
S Unanticipated costs;
S Court action against an employee or the organization itself.
Starting with these, we then ask what events might cause them. In practice, we have identified eight standard events, which we believe are common to most, if not all, organizations. We then invite the organization's own Information Security Forum (ISF) to add those that are the special concerns of the organization itself. The eight standard events are:
S Acts of God, vandalism and terrorism
S IT failure
S Denial of service
Events such as "Patient data we're meant to be protecting has appeared on the web", "Our mark-to-market valuation (for derivatives) is incorrect" or " The automated trains in our warehouse have just crashed into each other" are examples of such "user defined" events. Naturally, these will vary from business to business - the ISF's task is to examine its business and identify these specific events.
In developing an RTP, the idea is to ensure that wherever possible the occurrence of the event can be detected in sufficient time to do something positive about it before the impact occurs.
In some cases, it may be possible to prevent the event or detect it whilst it is happening and thereby prevent any further activity that may lead to an impact. Such are the preventive controls.
Having considered these, it is then necessary to consider the detective controls, if for no other reason than to appreciate that in practice the preventive controls may fail. The objective of the detective controls is to identify when some event, or events, have occurred that could lead to a materialization of the impact, and invoke appropriate actions to arrest (or mitigate) the situation. Finally, it is necessary to consider the reactive controls, which identify that the impact has occurred (e.g. because of a failure of the detective controls) and invoke appropriate actions to recover (or mitigate) the situation. The process terminates when management decides that any residual risk is acceptable.
Classroom and on-the-job training
Empowerment can only be achieved if the program facilitates knowledge transfer to the actors that will play the various
roles required by an ISMS. One way to do this is through formal classroom training, followed by on-the-job training and supervision.
We use a two day course covering both 27001 and (the code of practice which complements 27001), which teaches the trainees how to implement and administer an ISMS. It consists of a variety of lectures interspersed with syndicate exercises, and includes practice on developing RTPs. We can tailor this course by incorporating training on AIMS, and creating a one day session on internal ISMS audit. Again split between lectures and practice, this addresses both compliance and substantive audit techniques. We can then work with the client's ISMS team, to guide them in their early interpretation of the standard and determination of how to reflect their business within the ISMS in a way which makes the ISMS fit their business, not vice-versa.
The final ingredient of our methodology also concerns empowerment and is designed to ensure that the ISMS programme stays on course and to impart further confidence to the organization's staff in their ability to discharge their new responsibilities.
Activities usually include: