General Musing

blaze your trail

Implementation of Security #risk

with one comment

The lack of trained and experienced computer security people working in small to medium sized businesses today means that many times this is left to the regular IT departments to solve, if there even is an IT department. In many cases this leads to vendors educating the IT department on what are best practices, this is often to the advantage of both the vendors and the company. Important to remember is that such inequality and lack of knowledge on the part of the IT department can lead to a situation that when a vendor leaves the knowledge leaves with him/her. In the end the vendor is there to sell their software.

One of the primary mistakes is not understanding what it is that needs protecting, and making an analysis based on the risk profile of an IT asset[1] is paramount to a successful security implementation. An attempt to apply the same security rigor to all IT assets, regardless of their risk profiles, will surely lead to an unmanageable situation.

Logically documenting the current state of the IT implementation should be performed before anything else, even if this situation will may change completely. Only then will it be possible to identify the risk profiles of the IT assets, as there is a clear initial picture of the risks involved in losing a particular IT asset, naturally as the project to secure the IT assets matures this may change as more knowledge is gathered. Part of this phase is also to source and problem analysis: who or what will be a source of risk in the project. And what are identifiable threats that can cause problems during the implementation of the controls. It is required to identify all the potential sources of risk and problems. Both can be seen as potential technical issues, but also the stakeholders, shareholders, company employees and customers are potential sources of risk and/or problems. Although it may seem appropriate to evaluate the sources of risk and the problems, and solve these, identifying and inventorying is all that is needed at this point. This is not the time to get caught up in the details.

The next step is to plan the project, this includes an inventory of the remainder of the project. What security controls[2] are required to secure the IT assets. In the case of a friendly vendor and a small IT department this can be done together, although it is far too soon to be focusing on physical solutions, and only logical solutions should be considered. In this stage it is prudent to identify the identity and objectives of the various stakeholders, en establish a basic upon which the risks will be evaluated, called the constraints.

Among other things these constraints should also cover the CIA triad: confidentiality, integrity, availability of the information contained on the assets, as wel as the assets themselves.[3] Constrains should also cover the non-repudiation and accountability for the users of the system, and authenticity of the data. It is perfectly acceptable to not have a requirement related to the constraints, a system which does not contain data which needs to be confidential doesn’t need controls implemented to ensure confidentiality.

With this done a framework should be defined for the activity, and an agenda for the identification of the risks. Following which it is now time to develop an analysis of the risks that have been uncovered in earlier stages. Based on the assessment of the risks involved and educated guesses it is possible to prioritize the risks. In making this Risk Management Plan there is a fundamental difficulty in assessing the rate of occurrence without statistical data to rely upon. Evaluating the severity of the consequences (impact) for immaterial assets is often difficult. Asset valuation is also important at this point, which can add to the severity of the risks involved. One of the more common evaluations which can be used is:

Rate of Occurrence * Impact of the Event = Risk

Once the risks have been identified and assessed, a treatment or management plan can be developed. This usually fits in the following strategies:

  • Avoidance (eliminate)
  • Reduction (mitigate)
  • Sharing (outsource or insure)
  • Retention (accept and budget)

The avoidance strategy can be implemented when a potential risk can be eliminated. This is where knowledge of the logical security tools and assets are most valuable, all this for work has made it possible to be able to evaluate using a cost-benifit analysis whether it is worth it to take the risk.

When the choice is made to take the risk, the reduction stratagy is geared to make the risk as small as possible. However there are always risks for which the cost-benefit is high enough to live with the risk, but to either make it the vendor’s problem or to accept the risk.

Controls to affect risk can be either administrative, logical or physical. Administrative controls consist of policies and guidelines, such as password length and content requirements, or even the simple rule of not writing down a password. Logical controls are the usernames and passwords themselves, but also the access controls which are granted to the user once they have gained access to the system. And physical controls are as much the locked door, as they are the separation of duties between programmer and DBA.

Implementation of controls to affect the risk management strategies, such as authentication by way of username and password reduces the risk of unauthorized access while sharing the risk of abuse with the accessor. Two factor authentication – username and password, and accesscard – a control able to improve the accountability of the user and improve the authenticity and ensure the integrity and confidentiality of the data.

Once this point have been reached in the project, it is time to start over again, although not entirely from the beginning. What I mean by start over is to evaluate the value of the IT assets, part of this evaluation is an impact analysis in case of the loss of one of the IT assets.

To be continued…


  1. hardware, application, database, workstation, repository, accounting and billing systems, etc.
  2. Administrative, Logical and Physical (Passwords, Identity and Access Management, Firewalls, Intrusion Detection System, Intrusion Prevention System, Virus scanners and Network requirements)
  3. Also often mentioned are: authentication, authorization, reliability, maintainability, privacy, and certification.

Written by Daniël W. Crompton (webhat)

March 5, 2010 at 10:57 am

One Response

Subscribe to comments with RSS.

  1. Hi there I like your post


    March 23, 2010 at 11:16 am

Please Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: