Administrative controls. Policies, Procedures, Standards, and Guidelines. #class

CLASS_administrative_controls

## IT Controls Matrix

|               | Preventative  | Detective  | Corrective |
| ------------- |:-------------:|:----------:| -----------|
| Administrative|    Policy     |    Audit   |            |
| Technical     |               |            |            |
| Physical      |               |            |            |

## Definitions of Administrative Controls
+ Policy - Broad statement of management intent. **Example:** IT is responsible for secure configuration of endpoints.
+ Procedure - Instructions on implementing a policy. **Example:** All desktops will have antivirus software.
+ Standard - Detailed description of a control. **Example:** Symantec Enterprise Protection version whatever.
+ Guideline - Something optional. **Example:** You should run antivirus on your home computer.

As you move down the list you move from low detail to high detail. You also go from a document that is updated infrequently to a document that is updated frequently. Finally, as you move down the list, the amount of responsibility for the document also goes down. Policies may need to be approved by a Board of Directors and get review from labor groups and legal representatives while standards may be changed by the IT department without going above the department head.

## Parts of a Policy
A well-written policy will address the following items. These items do not necessarily require their own header in the document, but are often separated like that.
+ Purpose: why was the policy created and what do we hope to achieve
+ Scope: who/what does the policy apply to
+ Responsibility: who is going to make sure this is being followed? Who is in trouble if this isn't followed?
+ Last review: When was the last time someone looked at the policy to see if it is still relevant?
+ Review timeline: How often is the policy reviewed and who reviews it?
+ Exceptions: Who has the ability to grant exceptions to the policy and how is such a request made and documented?
+ Penalties: What kind of trouble am I looking at if I don't follow the policy?

Policies should always reflect what you actually want to achieve and they should be uniformly enforced. An organization should not write a policy that disallows ALL personal use of computers unless it is their intention that users may not EVER use their computer to check Facebook (not even on breaks). Organizations should not write a policy and then choose to enforce is sporadically.

Too often and organization will write a policy that disallows ALL personal use of computers and then choose not to enforce it. Later when a user goes way overboard in their personal use the organization will dust off the policy and enforce that. However, the organization is in the position of having to explain why the policy is not being enforced for anyone else in the office.

I **hate** policies that do not tell me when they were created, or last reviewed or when they will be reviewed again. I hate that almost as much as I hate blog posts that don't have a date on them anywhere. I want to know how out-of-date something is before I start reading it.

## Some Common Policies/Procedures/Standards
### Acceptable Use Policy
Almost every organization has a policy dictating what activity is allowed and disallowed on computer systems owned and managed by the organization.
+ Who owns these IT systems
+ Is there any monitoring in place? Do users have any assumed right of privacy on these systems?
+ Provides some examples of unacceptable behavior

#### To Sign or Not to Sign
Depending on who you ask some people will say that it is necessary for users to sign a document indicating that they have read and understand the Acceptable Use Policy or other IT policies. You should know that there are valid arguments in favor of both approaches and that this is not a settled topic in Information Security. People that favor signing the document say that it is necessary for accountability; signing the document gives a record that the user has been informed and can be held responsible. People that argue against signing the document point out that most other organizational policies do not require a signature and there is no reason for the IT policies to be elevated to such a level. If I show up at work with a gun or start sexually harassing all the women in the office I will face disciplinary action regardless of whether or not I signed any policy banning such behavior. The IT policies don't need special treatment.

### Data Classification Policy
The Data Classification Policy defines which data the organization controls and how that data is going to be classified and protected. For example, an organization may dictate that any data which has identifying information about a customer needs to be handled differently than memos and correspondance. This policy might dictate that customer information needs to be stored and transmitted in an encrypted state, for example. The policy should cover the lifecycle of information: Creation, Classification, Marking, Storing, Transmitting, and Destroying.

The Data Classification Policy is often referenced by other policies because the definition for various classifications will not have to be repeated. You might see text such as "Personal information, as defined in the Data Classification Policy, must be encrypted prior to being sent over email."

### Change and Release Management
If you have a secure system it will become insecure because of a change made to it. So Change Management is important to an IT Security professional. This policy should make it clear who can make changes to an IT system and what level of permission and review is required beforehand. Do you need to do any sort of review before adding a new user account or is the help desk ticket sufficient documentation? What level of outage requires notifying the users ahead of time and how much notice do we need to give them? The policy should require documentation of the impact of the proposed change and any rollback procedure that has been developed.

A couple thoughts on change and release management. 1. If you have a planned outage and the users do not know it was planned then the users will think IT is incompetent. Communicate more. 2. The most effective IT shops spend less time on repairing and more time on release validation. They have a baseline configuration for all their servers and automated processes to customize the server. They have detailed documentation of how each server deviates from the baseline. When a server fails they spent a short amount of time troubleshooting and then they blow it away and use the automated process to rebuild it. This leaves the IT workers with more time to develop and validate the next release because they aren't fighting fires all day.

### Account Lifecycle Procedure (aka User Management Procedures)
Covers the creation and management of Users, Groups and Permissions.
+ When to create an account
+ How to add the account to a group
+ When and How to audit an account
+ When to destroy the account
+ Dealing with transferred employees
+ Dealing with promotions
+ Dealing with re-hires.

One organization that I worked for allowed some former employees to keep their access for life. However, the organization would destroy the user account and create a new one with the same name. That ensured that the user did not accidentally retain any permissions on some old, forgotten system.

### Incident Response Procedure
Answers questions like:
+ What is an IT Incident?
+ Who is in charge of leading the response to the incident?
+ What is the escalation procedure?
+ When should we bring in outside support (law enforcement, forensic investigators
+ Who is on the Incident Response Team?
    - Security and IT Systems Administrators
    - IT Management
    - Legal and Public Relations
+ Who has the authority and training to collect digital evidence?

### Remote Access Policy / Procedure / Standard
The rules about remotely accessing the organizations data, the procedure for approving access, and the standard for devices doing remote access work.