Risk Management

In simple terms, Risk Management is looking at what you are doing business wise, determining any risks which may be associated with what you are doing, figure out how to make it less risky, and decided if it is worth doing (ie. an acceptable risk).

The goal of Risk Management is to make all parties aware of the potential risks. In some cases risks can be mitigated, however not every risk is expected to be negated or mitigated. Mitigation typically has a cost impact associated with it. There are always ways of making IT redundant to the nth degree - if you throw enough money at it.

For example, a manufacturer uses a certain widget in their product. A risk assessment may show that they obtain all their widgets from one vendor. There is a risk that the vendor could go out of business, suffer a disaster, etc. which would interrupt the supply of widgets. Ways of mitigating this risk could be to source the widget from another vendor. This could have an impact on costs (less from one vendor means less of a bulk discount) and the business needs to decide which is the safer solution long term.

Clayton State has an Enterprise Risk Management group. This group deals more with the large issues which affect the overall functioning of the University and it's ability to meet strategic goals. The risk assessments for individual systems deal with what would happen with the failure of that system.

From the USG Board of Regents IT Handbook

Procedures

The security plan for Clayton State has been evolving over the past several years. We have servers and services which have been running for years and we need to retroactively catalog, categorize, assess, and document those servers. We will start with the Critical/High classified servers and work our way down. For new servers, these procedures should be followed before they are brought online. This will be made a requirement of requesting a static IP address and DNS entry.

Risk Register

For each system, a risk register should be filled out which lists the risks, potential mitigation, potential impact and ranks the risks. An example Excel spreadsheet can be found here. The goal is to store all of this information in Wemedy for each service.

Categorize the Information System (criticality/sensitivity)

You need to figure out how critical the system is to the overall business operation of the University. While a service may be critical to one unit of the University, in the grand scheme of things, it could be done without.

You also need to look at the information which is stored on a system. If valuable information such as Social Security Numbers and Credit Cards are stored on the system, then the consequences of a security breach is a lot higher than a system holding other sorts of data, such as an inventory. While the inventory is still important data for that department, exposure of that data does not have the same effect.

Critical systems are those which the University could not continue to function without. Banner is a key critical system as all of our student records are stored within the database, and teaching of classes are our primary business. LANDesk/ServiceDesk, which critical to The Hub to offer support, is a system the University could do without if it were to fail as there are other ways to provide support and track problems. They may not be ideal, however they are workable.

Select and tailor baseline (minimum) security controls

We have minimal standards that all systems must abide by and have controls in place to enforce those. For example, the firewall blocks any incoming traffic by default. Any machine on the domain has the Windows password standards enforced, and workstations lock automatically. In some cases, some tweaking may be needed, but we try to keep our baseline standards as rigid as possible to provide the same level of protection to all systems.

Supplement the security controls based on risk assessment

As mentioned above, not every risk can be cost-effective to mitigate. For critical and sensitive systems, it may make more sense to mitigate the risk. With the above inventory server, you may not need a redundant server in case of a crash. But with the domain controller, which authenticates users for almost every other system, you may want to have more than one.

Document security controls in system security plan

As you look at the controls required to go on a system, you need to document that they are indeed put in place. When auditors come through and look at what was done, you can pull up a document showing the machine was joined to the domain on a given date, which then met the security controls for passwords. This also serves as documentation for what was done for a system to secure it.

Implement the security controls in the information system

This should mostly go hand-in-hand with the documentation. Once you decide what controls need to be in place for a system, you need to implement them (and then document that you did so).

Assess the security controls for effectiveness

Trust...but verify. When a control is implemented, you want to make sure that it does work as intended.

Authorize information system operating based on mission risk

Once the risks have been assigned, mitigation has been done (where feasible), then the senior level needs to give the go ahead for the system to be used. This allows some checks and controls.

Monitor security controls on a continuous basis

You need to make sure that the controls continue to function. While every effort is taken to work together and coordinate, something may get missed, and what seems like a benign change could cause a control to stop working.