Risk Assessment (0)

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