Risk Assessment

Requirement elicitation is a process performed by analysts who gather and understand information. This process involves the following factors:

Fact-finding. Fact-finding uses mechanisms such as interviews, questionnaires, and observation of the operational environment of which the system will become a part.

Validating the customers understanding of the gathered information. Validation involves creating a representation of elicitation results in a form that will focus attention on open issues that can be reviewed by those who provided the information. Possible representations include summary documents, usage scenarios, prototypes, and graphic models. A requirement proposal, requirement communication, and requirement definition achieve requirement elicitation. A requirement proposal outlines the need for customer requirements.

As IT has gotten more involved in business processes, IT has become closer to the politics in the organization. In the past many IT groups fell under finance or accounting. Some have said that because of this, many accountants and heads of finance became CEOs — through the use of the information and capabilities of IT.

Today, IT cannot avoid political involvement. How a new system and process are implemented affects the power structure of the winners and losers. Politics sometimes generates new project ideas. Projects can be started and then later killed for political reasons. For example, manager A starts a project. It appears useful, but manager A moves on and is replaced by manager B. Manager B then either changes or kills the project. The new manager is “putting her stamp” on the work.

1. Functional gaps open up
You review a system that meets most of your requirements and rates well against competitors. Should you acquire it?

Most product evaluation methodologies only evaluate the fit of the current product against current business requirements. An underlying risk when acquiring technology products is that the successor product may be less well aligned with emerging business requirements. This has most to do with the vendor’s capability and product development track record but is unfortunately often overlooked when an out-of-the-box solution appears to offer a fast track to the desired (short-term) solution goal.

Over time as functional gaps open up, greater effort needs to be ploughed into modifying or working around the solution. The paradox is that with every modification you further commit to the increasingly ill-fitting system.

2. Aggressive upgrade cycles
When you are changing software because your vendor has released a new version (and withdrawn an old one) and not because you perceive any great advantage from moving, you are in the upgrade cycle. When you are changing hardware because your new software won’t run on the old hardware, you are in the upgrade cycle.

There are two major goals of a network vulnerability assessment (NVA). The first goal of a technical vulnerability assessment is to test everything possible. The second goal of a technical NVA is to generate a clear, concise report that will be read and used by your management or your customers

To test everything possible is often useful to think in "new-age" terms and consider the NVA a holistic NVA. The reason that it is important to test the entire security domain is somewhat obvious. An intruder only needs one hole to break into the network; if that hole lies in the primary firewall or through a modem connected to an executive's desktop computer, it really does not matter. There are some factors that will limit how deep you can make the NVA.

Most of us put a lot of effort into cost estimation in our personal lives. When considering a new job offer, most of us look closely at the cost of living in a different area; likewise, when shopping for a new car, most people check with several dealerships to find the best deal. The business world is constrained by the same budget factors. These components drive up the cost of software:

• The chosen source code language—Using an obscure or unpopular language will most likely drive up costs.
• The size of the application—The size or complexity of the application has a bearing on cost. As an example, the level of security needed is something that will affect the complexity of a given application. This also has a direct correlation to the scope of the project.
• The project time constraints—If a project is projected to be completed in one month versus three months, this might mean that more overtime needs to be paid, along with fees for rushed services.

There are a lot of definitions of IT risk, but, before let you know that every business venture is basically risky. In new business ventures and new product development, there are unknown factors and their impacts on the venture are equally unknown. The unknown factors could be favorable or unfavorable. There is a probability that one may either gain or lose. However, a loss may hurt the venture. Here are some of the definitions:

1. Risk is the probability of suffering loss.
A refinement of this definition is to include goals, gains, or opportunities in the statement. Perhaps it is implied and obvious that risks are connected with gains. Nevertheless, if risks are divorced from the associated goals, then one sees just a set of problems. A risk list should not be reduced to a problem list. Risks have a much broader role to play.

1. Unique user ID and confidential password required    
2. Additional identification required for remote access
3. "Help" screen access available to logged-on users only
4. Last session date and time message back to user at sign-on time
5. Exception reports for disruptions in either input or output
6. Session numbers for users/processors that are not constantly logged in
7. Notification to users of possible duplicate messages
8. Threshold of errors and consequential retransmission on the network related to management via automatic alarms
9. Encryption requirements    
10. Encryption key management controls
11. Message Authentication Code requirements for nonencrypted sensitive data transmission
12. System authentication at session start-up (wiretap controls)
13. Confirmation of host log-off to prevent line grabbing
14. Downloading controls for connected intelligent workstations
15. User priority designation process
16. Transaction handling for classified communications
17. Trace and snapshot facilities requirements
18. Log requirements for sensitive messages
19. Alternate path requirements between nodes
20. Contingency plans for hardware as well as all usual system requirements
21. Storage of critical messages in redundant locations
22. Packet recovery requirements
23. Physical access for workstations when units are not in use

After you or your company makes the decision to use a penetration testing vendor, the next step is to choose the appropriate vendor. The factors you should consider are as follows:

• Confirm liability insurance —Make sure the company provides adequate liability insurance in the event of unapproved damaging consequences of testing.
• Ask for references —The company might have previous clients that you can talk to. Many customers do not want their name given as a customer for privacy reasons, but some companies are willing to discuss their experience with penetration testing vendors.
• Perform background checks —The company should either provide you with documentation on criminal background checks of employees, or you should perform your own background check on their employees.
• Ask for sample reports —These should not be actual reports. If they are, who is to say that the vendor will not use your report as an example for another potential client? Avoid doing business with vendors who provide you with real reports. These sample reports should be generic reports without a reference to company identities, IP addresses, or host names.

To perform a good network vulnerability assessment, you should incorporate at least four elements:
• Comprehensive
• Experience
• Results must be reproducible
• Multi-Test Environment (MTE)

The comprehensiveness
The comprehensiveness of your network vulnerability assessment will be affected by two major factors. The first of the two encountered will be the amount of time you can dedicate to the network vulnerability assessment; the second is the amount of capital resources you can devote to the network vulnerability assessment itself.

1. Piecemeal approach
Organizations do not take a holistic approach to IT risk, where risks are determined throughout the organization and then assembled into a corporate score sheet. Most commonly, strategic risks will be assessed at the time that a project is initiated – and then forgotten. Project risks will be assessed only by those responsible for carrying out the project – a guaranteed conflict of interest. Partner risk will be assessed only at contract rollover, if at all. Degrading infrastructure assets are seldom formally valued. And so the story goes on. Each risk component has its own ad hoc treatment, if anything. [Beating IT Risks, Ernie Jordan and Luke Silcock]

2. Communication failure
Technical risks discovered by the network manager or a project manager may well be incomprehensible to the board, where decisions must be made and accountability ultimately resides. The challenge of communicating an issue from technologist to IT manager or business manager and then to a director will be similar to the challenge when the concern is travelling in the other direction. In addition, those responsible for finding risks may not be rewarded for communicating them, giving them a ‘whistle-blower’ pariah status.

3. Surprises and reactivity
We are continually surprised at how managers are continually surprised when things go wrong. Things do go wrong! Hardware breaks down,