I came across a post on Jesper Johansen’s site today about the Required Attributes of Security Solutions. It is an interesting list of attributes that any security solution should have. Being that I am in the midst of an accounting class, I quickly made an association between the attributes of the two….
First the Principles of Design
Cost-Benefit Principle – This Principle states that the benefits derived from the system should be equal to or greater then the systems total cost. This holds true for both accounting and security systems, for instance it would not make sense to purchase a security system at a cost of $1m (with a 5yr lifetime) that could only ever prevent $500k in damages (material or immaterial) over the same lifetime.
Control Principle – This principle requires that the system contain it’s control procedures so that data are reliable. This means several things to the system. The system should allow for risk assessments as an input to allow for changing environments. It also means that there must be control activities in place like policies and procedures to govern how the system is used. Other activities that are lumped here are authorization, so that controls of changes to the system are authorized.
Compatibility Principle – The system must be in tune with the organization’s business and operating environments. If there is a distributed company in different cities or countries, the system should be designed specifically for that environment. On the other side of the fence, if the company goes through a transition and moves from several remote offices to a single HQ, the system must be re-evaluated to address the new needs of the company.
This continues to hold true for people and the actual business of the company. Training the employees on how to use the system is critical. This means proper classification and other human components. If the company is in the business of selling wheat, the system should know how to secure those transactions and the operations of that kind of business.
Flexibility Principle – The system must be flexible enough to allow for growth of the company. This includes being able to handle new product lines, different ways of handling business, and regulatory changes that may affect the requirements of the system
Measurement
The Matching Issue – Matching situations with when they occur is critical to ensuring they are measured properly. Events and transactions must be matched with the time in which they occur. If event ‘A’ and event ‘B’ are both discovered on day 15, it will be very important to know that event ‘B’ happened on day 3 and event ‘A’ happened on day 10. This enables a view into the relation of the two events and their potential impact is more apparent.
Adjustments – Adjustments must be included in the measurement. If an operator adjusts the system, this must be measured so that it can later be reported on properly. Without this type of measure, malicious or mistaken operators can cause problems for the business.
Reporting
Regular reporting – regular generation and distribution of reports is important. This includes external regulatory bodies, internal audit departments, managerial staff, and executive leadership. It is crucial to have this reporting based on the design and measures discussed above. These reports must also have the conventions below so that the consumers of the reports can make real decisions based on the content.
Conventions to assist in interpretation
Compatibility and consistency – The data collected and the method it is presented in must be similar through time. Without this, changes in the environment cannot be followed and problems will not be immediately apparent. Management needs to be able to read the reports and make quick decisions based on those reports. Should the company decide to change it’s practices, it must be a very well thought out process that allows for plans to relate the old way to the new way of measuring the environment.
Materiality – This refers to the relative importance of an item of event. So if an item or event is material or relevant enough that a decision would be different without the knowledge, and then the system must include it. As an example of this we can look at a case where several users are bothered by someone regarding a test system upgrade, a couple of weeks later a test system begins to act up and needs to be rebooted, a couple of weeks later the same thing happens in production, and week after that the production web farm is compromised. Had the relevancy been given to the first two incidents, this could have been prevented.
Conservatism – This one is pretty basic, the system should not “cry wolf”. A system that begins this kind of life will have a very short life. No events and reports should be over emphasized, only if something is actually serious (in the opinion of the team that runs the system), it should be brought to senior management’s attention.
Full Disclosure – This one differs a little between the two systems, although it is important to tell people what you are monitoring for security, it can also be a benefit not to do this.
Cost-Benefit – Repeated again here, the cost benefit of the system’s reporting capabilities must outweigh the risks it prevents.
To compare this with Jesper’s original list
- Comprehensive <- -> Materiality, Compatibility
- Comprehensible <- -> Cost-Benefit, Compatibility
- Adaptable <- -> Flexibility Principle
- Centrally manageable <- -> This is not listed above – but as a basic attribute does this make sense for a global company with multiple HQs or separate operating entities?
- Enforceable <- -> Control
- Reportable – Measurement, Reporting, Compatibility and Consistency
So let me know what you think, Do you agree on these, did I miss anything or not account for anything that was more important in Jesper’s post……