Risk Management Lectures (4)

The following series represents lecture material that I’ve used from time to time in discussing the problem of IT Risk Management. I’ll be providing this material on my blog as a series of information related to the topic.

***

Risk Assessment Process

We recognize that technology isn’t cool-it is critical to ongoing business operations. Therefore, securing the information system requires a multifaceted approach as the electronic information system poses a significant risk the organization.

1. Risk of loss or damage
2. Risk of exposure or compromise
3. Risk of regulatory non-compliance
4. Risk of obsolescence and incompatibility

Lack of attention to managing the information systems security exposes a company to increased risk and liability because of the perception that management did not respond to their obligations. So on the one hand when a management implements ATP controls and safeguards, they’re responding to the need to mitigate the loss of an asset, yet they are also demonstrating their reasonable response to potential exposure. Also, management may implement these controls and safeguards in response to regulatory compliance and business continuity preparations that had been placed upon them by government agencies. In some situations, the lack of “due care” can actually result not just in civil penalties like fines and citations, but may also result in criminal prosecution.

Quantitative Risk Assessment Qualitative Risk Assessment

There are various Risk Assessment approaches and methodologies but, generally, they can be broken down into two camps: methods that are more qualitative in nature versus quantitative in nature.

Qualitative approaches tend to address the emotional response we have to a disaster incident and built a prioritization of response based on _perceived_ importance. A good example of this is the FRAP (Facilitated Risk Assessment Process) method as espoused by Peltier and others that encourage dialog, surveys, and solicit opinion to determine perceived areas of risk within an organization.

Quantitative approaches attempt to quantify – usually using financial metrics – the loss to an organization if a disaster was to occur. Quantifying the risk of disaster is referred to PARA (Practical Application of Risk Analysis) techniques. Often there is a mechanism by which to determine the potential loss of an asset based off the probability (the risk) of the incident occurring, thus you could apply that single loss expectancy to an annualized rate of occurrence to arrive at an estimated annual loss. As a manager, this financial number could be compared to the cost of insurance, for example, and weighed against the conceivable cost of a countermeasure.

Qualitative approaches attempt to gain a sense of urgency, priority, and the significance of risk by employing discussions, focus groups, and surveys. These assessments rely – typically – on the perceptions and opinions of employees in order to arrive at criticality and risk. FRAAP (Facilitated Risk Analysis and Assessment Process) was developed by our author, Peltier, as a quantitative method for analyzing and prioritizing risk assessment. Peltier’s presentation is highly-organized and thorough FRAAP’s outcomes lack the convincing nature of monetary values

In the coming weeks, we will be exploring both quantitative and qualitative ways to conduct risk assessment (RA). I think it’s safe to say that we will conclude that a purely quantitative RA method is not 100-percent accurate; that we require a qualitative RA method to counterbalance what numerical assessments miss or cannot foretell. Using one RA method exclusively is probably too narrow of an assessment that could have the potential of being too myopic.

To quantitative risk analysis, RA is an assessment practice to:

1. Identify a company’s assets
2. Assign values to assets
3. Identify the assets’ vulnerabilities and threats
4. Calculate their associated risks
5. Estimate potential loss and damages
6. Provide solutions and remedies that do not exceed the value of the asset

To qualitative risk analysis, RA is an assessment practice to:

1. Identify a company’s assets
2. Ascertain risk through the collection of opinions and observations.
3. Determine a scope of effect if the asset were rendered unavailable.
4. Prioritize risk based on the impact of the scope of effect.
5. Provide solutions and remedies that either constrain the scope, or, mitigate the risk.

Notice that there are similar, traditional steps to RA regardless of method. We identify assets, we attempt to valuate assets, we attempt to identify how our assets are vulnerable to damage or loss, and we attempt to calculate the financial (or qualitative) risk associated with the loss. Finally, an outcome of RA is to “provide solutions”, or, recommend safeguards that would address the vulnerability of exposure and potentially mitigate or eliminate the risk of financial loss to an asset.

Given our understanding of this process, we can see a distinction between RA and financial analysis and auditing functions. RA deals with evaluating the _risk_ to assets; financial auditing attempts to evaluate the current _value_ of assets. Financial audits attempt to confirm the validity of accounting records to GAAP principles, and provides transparency of accounting practices to stakeholders; RA is a method to expose vulnerabilities and setup a framework for responding to them. This is good to remember as many second parties to our companies (our financial auditor, insurance auditor) are getting into the RA business and are attempting to market their services in parallel to RA, which may be a dangerous situation, considering that the RA investigates holes in information systems, while, the financial auditor relies upon the integrity of the information system to arrive at their conclusions. Hence you have a fox guarding the hen-house kind of problem.

RA exposes risk to vulnerabilities and attempts to communicate to management some quantification/qualification of that risk, so that management can respond; take action; implement Administrative, Technical, or Physical controls to reinforce the CIA Triad.

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.

Risk Management Lectures (3)

The following series represents lecture material that I’ve used from time to time in discussing the problem of IT Risk Management. I’ll be providing this material on my blog as a series of information related to the topic.

***

Business Strategy Effects

Risk Analysis helps us determine effect of disasters upon business strategy.

In his text, Peltier rationalizes that risk analysis should happen whenever time, money, and resources are to be spent, as a way to balance operational needs against increasing costs. Risk assessment is a tool that allows a firm to identify potential disastrous circumstances and prioritize a response to mitigate the risk. Peltier describes the risk management process on page nine as conforming to five standard steps or principles:

1. Analysis
2. Design
3. Construction
4. Test
5. Maintenance

As described on page 10, these steps are just a generalist way of performing a risk assessment. Risk assessment, risk management, isn’t new – firms have employed techniques of varying complexity to this model for decades – yet, in the field of information technology, 9/11 opened a lot of eyes to the potential of catastrophic loss and business continuity has been a hot topic in boardrooms ever since. In his introduction, PdIn taking this course, it should become apparent to you that technology implementation without consideration towards disaster recovery is both a severe strategic oversight, and, an uncomfortably stagnant position that monopolizes IT function on the needs of now rather than on the contingent needs of tomorrow.

Client/Server and Peer-To-Peer Architectures Centralized, Distributed, and Stand-alone Architectures

Over the course of the class, we will be discussing various forms of computer architecture and information assets that could be put at risk. It might be useful then to quickly review a couple of concepts concerning scale.

Principles this week concern scale – the evolution, size, complexity, raw processing capability – in component relationships within an information system. As organizations migrate from peer relationships in their computing platforms, they move to more structured, centralized models typically representative of client/server networks.

In peer relationships, services and security contexts are limited to individual microcomputers. In order to manage services and security, you must administer these things directly on the affected computer. As the network grows and business practices become more reliant on the electronic information, this practice can become horribly anarchistic: every computer has its own security context and needs to be managed separately. Over time, the chaos and management overhead eventually leads to a loss of control over data and information services.

Therefore, as organizations mature their information services, they begin to centralize their computing platforms into in client/server relationships: security and services are centralized to a computing platform – a single security context – designated to perform a service function for the network – a server – whereas a client would be a machine that requires use of the service offered by the server. The security context is centralized to the server so that access restrictions may be managed from one point; configurations relating to security can be made on the server, and, any client computer willing to use the server’s resources are subject to that security context.

In client/server relationship models, we’re offering services for dynamic access and use by client machines; the engineering problem is to maintain uptime whereas the support focus is to educate end-user communities to access, leverage, and exploit these services for business process efficiency. Services rendered unavailable generate a very visible denial of access and potential failure of dependent network services and is relatively easy to troubleshoot: the service is working, or it is not; the equipment is online, or it is not; the file is available, or it is not.

The client/server network is therefore primarily concerned about redundancy and fault tolerance if only to maintain the operating system’s stability to offer these services. This isn’t an extraordinary engineering feat anymore – modern operating systems on 32bit and 64bit platforms are remarkably stable following installation, are often equipped with API’s (Application Programming Interfaces) to make managing applications residing on the platform integrated with services and security contexts’ offered by the o/s, and patching is nearly automated. However, performance is measured on both service availability and file availability and the suffering performance usually translates into a minor inconvenience until such time the service and file are brought back online. Ten minutes or ten hours, the lost productivity may be measured but there’s little or no risk to the rest of the information system.

As information systems mature, the reliance on transaction based processing continues to grow, whereas the dynamic of downtime changes; the TPS (Transaction Processing System) layer becomes important to many levels of DBMS processing managing fulfillment obligations on behalf of the company. The role of services and files in client/server begin to diminish – the engineering problem has matured. The problem no longer becomes an inconvenience in a lost service or file, instead, it becomes what to do if, even for two seconds, unavailability results in transactional error or data malformation. The TPS is part of a larger problem in moving data in more real-time from one processing state to another, whereas downtime isn’t an inconvenience, rather, it’s a catastrophic event with enormous consequences to upstream and downstream systems that are also integrated the TPS layer.

So, over time, as investments in information systems grow for a company, they watch their information services mature from client/server architecture to a data center architecture, where the concern isn’t simply for files and services, but, for transactional speed, accuracy, and reliability. Therefore the engineering problem shifts. Our concern is for inspection, for buffer and capture and spooling if another portion of the transactional process is brought offline. The programming and engineering problems concern memory management, I/O constraint, verification and translation activities across multiple DBMS channels. The data center becomes a heart beat – a pulse – for the organization. If the pulse stops, if even for a few moments, the results could be disastrous.

Within the course, we’ll talk about peer/peer networks, client-server relationships, and data centers – even so much as to evaluate these configurations with our case study, Omega Research. In this case study, you’ll be tasked to evaluate the relative risk given facts presented in the case, and asked for your opinion for addressing/mitigating those risks.

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.

Live Santa Tracking Map

Track Santa in real-time as he travels across the globe!
http://www.noradsanta.org/en/map/index.php

R
www.micklerandassociates.com

Risk Management Lectures (2)

The following series represents lecture material that I’ve used from time to time in discussing the problem of IT Risk Management. I’ll be providing this material on my blog as a series of information related to the topic.

***

Avoiding a Common Misunderstanding

The word “disaster” has a particular social connotation that suggests absolute calamity, death, destruction, and mayhem. This is, in fact, a dangerous perception because we could easily become lulled into looking at “disaster” from a single lens. We are “safe” so long as we relocate our data center to a region with relatively little natural catastrophic activity, which couldn’t be more distant from the truth. As Toigo points out on page 47, figure 2-3, the vast majority of information system disruptions arise from more mundane causes – human error and malfunction – than that are the result of natural disaster (just 3% as compared to 90% of leading causes).

Also, a “disaster” situation doesn’t necessarily mean property loss or evacuations – but that kind of effect on dependent business processes could still be suffered if a transformer malfunction prevented a cold restart of a major computing platform. Scale is not as important as effect.

The CIA Triad

In analyzing the security of the information system, we are chiefly concerned with three elements concerning its security. Confidentiality, integrity, and availability of information systems reflects upon the relative security of the system. Confidentiality refers to the way that an information system is capable of allowing those who have a right to know to have access to information.

Confidentiality also refers to the way that an information system is capable of identifying those who do not have the right to know and access to information. An information system with a weak Confidentiality safeguard would be incapable of distinguishing those who have a right to know and those who do not have the right to know.

Integrity refers to the way that the information system is able to log, track, audit, and demonstrates how it was able to maintain confidentiality. An information system with a weak integrity control would be difficult to review an audit to verify if it had indeed performed correctly in enforcing Confidentiality. An audit of this information system would not be possible. Verifying the information system and its safe guards would be difficult if not impossible.

Finally, availability refers to the way that information systems are extended to those who need the information and at the time that they need the information to make a reasonable decision. Availability in some ways also reflects upon accessibility. An information system with weak consideration for availability would diminish its overall usefulness; if information cannot be provided to those who require it at the point when they require it, then the value of that information system is relatively moot.

In considering the CIA Triad, we can see that this is a significant design challenge for any IT function. On the one hand, availability can be sacrificed to ensure higher degrees of confidentiality and integrity. However, on the other hand, Confidentiality could be sacrificed for more openness and ability to share information with others. And, finally, integrity could be sacrificed so that the information system could be both available and accessible by all users.

We must remember that security is nothing more than the confidence that we feel in evaluating the safeguards that are then taken to protect the information system. If security is a measure of confidence, then we will have more confidence if more steps are taken to preserve the CIA of the information system. So therefore, our analysis concerning the security of an information system begins with the confidence we have in the overall controls needed to enforce the CIA Triad.

Next Time: Risk Analysis as a Tool to Determine Effects of Disasters on Business Strategy

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.

Risk Management Lectures (1)

The following series represents lecture material that I’ve used from time to time in discussing the problem of IT Risk Management. I’ll be providing this material on my blog as a series of information related to the topic.

***

Introduction – Vulnerabilities and Inherent Risks of Computer Systems Risk Management and Contingency Planning are relevant because of the interdependent nature of business processes and technology.

Before beginning our conversation, it may be helpful to define Disaster as slanted in the scope of your academic program – information technology. For the purposes of this course, I will suggest that a disaster is a condition in which an information resource is rendered unavailable, and by way of an information resource, we would mean hardware, software, databases, telecommunications, and human capital.

I don’t mean to dismiss the obvious or sound crass. Certainly there are human tolls to a disaster, physical and psychological, significant losses to property and life that we’re only recently too familiar with. These are important factors – life being, absolutely, the most important – however, practically we must leave them outside of the scope of our studies.

In this class, we will be examining ways that organizations can recover from situations where an information resource is made unavailable due to causes ranging from the catastrophic to the mundane. Regardless of scale – from a faulty hard disk to a hurricane – the result is often the same. Information outages:

1. Cause significant disruptions in supply chain activities that impact net margin;

2. Reduce the speed, accuracy, and reliability of data processing functions that diminish economies of scale;

3. Diminish the Confidentiality, Integrity, and Availability (CIA) of information.

There are larger questions here that I’d like you to consider: let’s forget what a disaster is or isn’t – instead, why should corporations respond to disasters? And how should companies respond to disasters? In answering the first question, I will present you with the obvious, and in answering the second question, I will mostly likely shock you.

The obvious answer of “why” is related to the increasing dependence upon technology to reduce transaction costs and improve the speed, accuracy, and reliability of internal business processes. Since the 1960’s, American firms have gladly invested financial resources into fixed capital assets that increase internal productivity without generating extra labor expense, the effect generating increases in production volume without a corresponding increase in cost – particularly labor. Today, an era of intense price and value competition wherein firms compete in global capital and product markets, investment in information technology is only more of an imperative to competitive survival.

Yet despite this obvious connection between information assets and viability, research from the Gartner Group suggests that two out of five companies that experience an extended system outage (a disaster) never resume operations again; of those that do recover, a third are out of business within two years.1 Further, according to the analyst firm META Group, fewer than 25 percent of Global 2000 enterprises currently have a comprehensive and tested business continuity or disaster recovery in plan in place.2 Lastly, in examining the other-80-percent of the economy (small business), according to a 2004 article by SmallBizPipeline.com, a survey of 237 small businesses found that 73% of those surveyed had no written plan that defines a strategy for responding to disaster.3 In that same survey, 56% of those who actually measure potential loss from disaster responded suggested that they would lose less than $10,000 per day.4

What this is to suggest is that firms would rather ignore the risk of disaster than adequately plan for it, even though the statistical facts would suggest that a disaster incident of significance has a considerable chance of forcing the company to close its doors, or, in the least, be the cause for material daily losses. Therefore, our how question is starkly answered: we ignore it, and, we hope it never happens to us. Sound familiar?

References:
1. Unknown Date. Doherty, Michael. “Open For Business: Disaster Recovery Plans Save Small Business.” Found on the World Wide Web on November 15, 2005. URL: http://dohertyassoc.com/articles/disaster_recovery.pdf.

2. 2002. No Author. “The Crucial Role of Vital Records in Business Continuity/Disaster Recovery.” Found on the World Wide Web on November 15, 2005. URL: http://www.mediaprotection.com/gfx/fkwhitepaper.pdf.

3. 2004. Smith, Tom. “For Small Biz, Data Protection Supersedes Disaster Recovery.” Found on the World Wide Web on November 15, 2005. URL: http://www.smallbizpipeline.com/security/19502003.

4. ibid. URL: http://www.smallbizpipeline.com/security/19502003.

Next Time: Explaining Disaster and the CIA Triad

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.

How to Disable Update Restart Notifications

Perhaps you’ve seen this annoying message in Windows XP SP1 or higher:

It’s Windows politely reminding you to restart your computer after applying some recent updates in the background. Useful, but really obnoxious because the refresh rate on this is under five minutes and it will continuously annoy you until you restart your computer.

To disable this obnoxious behavior, you can use the Group Policy Editor on your Local Machine.

1. Do a START, RUN.
2. Type in gpedit.msc, and hit ENTER.
3. The Group Policy Editor will load. The default object is the Local Computer Policy.
4. Select Computer Configuration.
5. Select Administrative Templates.
6. Select Windows Components.
7. Select Windows Update.
8. Select Re-prompt for restart with scheduled installations.

Once doing this, the following dialog will be presented.

ENABLE it and set the time in minutes. Example, 240 minutes would be once every four hours – that’s not bad. You’d think the option DISABLE would work but it actually treats the policy option like a “Not Configured”.

Finally, you must force the Policy to take effect.

9. Make the change. Confirm okay.
10. Close the Group Policy Editor.
11. Do a START, RUN.
12. Type the following: gpupdate.exe /force
13. Press ENTER.

A DOS window will flash as the group policy is forced to take effect.

Unfortunately, this doesn’t work on the HOME edition of XP. And a little word of caution if you’ve never been introduced to the Group Policy Editor before: don’t. As in, “Don’t mess around with it if you don’t know what it does.” (i.e., fiddling around with the Registry isn’t for the faint of heart). Make this one change, follow the instructions, and get out (grin).

R
www.micklerandassociates.com

New e-Discovery Rules Take Effect

On April 13, 2006, the US Supreme Court approved amendments to the Federal Rules and Civil Procedure to treat electronic documents in the same manner that paper documents have been treated in the discovery process. The changes went into effect Friday December 1, 2006 and force companies to have email, instant messages, electronic chat correspondence, and other forms of electronic documents and communications available when requested for federal trials. State and local jurisdictions may use the new rules as a guiding set of principles.

Although the changes to the FRCP do not articulate a specific penalty for violation, companies who’re unable to produce electronic documents during litigation could suffer losses, be unable to prove a claim, or could result in contempt of court rulings or technical violations.

This has practical application and real significance upon IT data archive and retention policies. For example, in my experience as a technology director, in the past, I would advise corporations to develop control policies that permanently deleted email records after 45-day time frames. The court would defer to our own data archive and retention practices to justify the reasonable duration for retaining such records, meanwhile, allowing the corporation to naturally expunge potential email evidence that could be requested during discovery. This action wouldn’t be criminal, it was practical: doing so limited the scope of liability for the company and the complexity of the data archive. If the data was unavailable based on our own policies, then they were reasonably unavailable for discovery.

Now, following the December 1 changes, this can no longer be recommended. These rules confer an obligation to disclose electronically-stored information and retain these records as we would paper records of similar content. Even legal holds in discovery now apply to electronic records which can force companies to preserve e-records in advance of audits, investigations, or litigations. In short, the legal landscape has changed and companies must be prepared to review their data retention and archive procedures for a major overhaul in 2007. Companies should:

1. Review their data classification policies to identify electronic forms of communications that fall under the new e-discovery guidelines. Time frames for retention, responsibilities for access, destruction guidelines should all be stipulated. This has even more significance if the company falls under HIPAA, GLB, FERPA, and other forms of protected personal private information (PPI) regulatory procedures.

2. Adjust their data archival and retention policies to reflect new expectations for data lifecycle. This would include first-round data backup procedures for business continuity, then second-round data archival for business continuity, then third-round procedures for historical preservation. The connection between the classification policy and the retention policy should be clear: classification identifies the data to be handled and sets guidelines for its handling; retention and archival policies execute technical procedures to reflect classification mandates.

3. Review and adjust business continuity and disaster recovery policies to restore specific forms of data outlined in the data classification policy following a disaster event.

4. Review media destruction processes and establish a clear record for media serialization, retention, and destruction, as a part of the retention and archival policy.

In summary, the business should demonstrate a clear line of management intent that:

1. Identifies information and data sources considered as reasonable targets for discovery;

2. Sets clear policies on how to use, retain, preserve, and destroy such information and data sources;

3. Sets unambiguous procedures that execute the classification, retention, and archive policy.

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.