Ten steps to secure control systems

The importance of training is especially evident in thwarting hackers who try to gain access to system resources through social engineering. Social engineering is the practice of convincing people to willingly divulge confidential company information, such as passwords. The result of a social engineering exercise I once commissioned was abysmal – 50% of the people contacted in four sites located in three countries divulged their user IDs and passwords to the ethical hacker. We immediately embarked on an extensive security awareness program to try to improve the results.

What we discovered were two things. First, once people understood how hackers worked and how easily they could do damage to the company they became enthusiastic supporters of security initiatives and policies. Second, we discovered that any given communication method only reached about 20% of the user population. 

At first we tried mandatory classes. While those that attended them rated the classes very high, only about 30% of the people for whom the class was mandatory actually attended it.  We then branched out to a monthly newsletter (changed to quarterly after 6 months), posters (tied to company advertising themes and programs) at the common entrances to major offices, global “security awareness days" (booths were set up explaining security policies and tools, vendors were invited in, trinkets with security themes were handed out, etc.), set up an “asksecurity” email that anyone could use to ask a question or report a problem, and scheduled one-on-one visits to business executives explaining why information security was so important.

After twelve months we repeated the social engineering exercise. We were hoping for a 50% reduction in the number of employees divulging critical information. What was achieved was that no one gave up any critical information such as User IDs or passwords, and 20% of the employees contacted by the ethical hacker reported the incident.

Security awareness training can be very effective. But, to be effective, the training must communicate WHY information security is important and it must use several different methods of communicating the message.

Policies and Procedures
There are accepted standards for how to structure policies. Typically they are divided into categories called Operations Policies, Procedural Policies and Technical Policies.

Operational Policies
Operational Policies are the high level statements of objectives, followed by the standards and guidelines associated with each policy statement. For example, Policy Statement 1.1 might be “Scheduled Reviews: The Cyber Security Policies for COMPANY will be reviewed according to the following standards and guidelines”.

Standards are actions related to achieving the objective of the Policy Statement that MUST be followed. Guidelines are actions related to achieving the objective of the Policy Statement that SHOULD be followed. Usually, one of the Operational Policies will be related to granting exceptions to policy. If it is impossible (either technically or due to impaired business functionality) to adhere to a Standard, an Exception to Policy request is required. 

Procedural Policies
Procedural Policies are repetitive actions required to accomplish a process, usually associated with an Operational Policy. For example, required procedures from a cyber security perspective would be the process for monitoring logs (the reports/log files that will be reviewed, how often, etc.) and the change management process. Frequently, Procedural Policies are documented using flowcharts or other similar process-capture method.

Technical Policies
Technical Policies are structurally very similar to Operational Policies, but are focused on the more technical aspects of achieving an Operational Policy. For example, an Operational Policy may require passwords and specify some general standards regarding their construction, aging, expiration, etc. The associated Technical Policy would specify in detail how this would be implemented (types of characters allowed, specific length, etc.). Since different systems have different technical restrictions on what can be specified, they will each require different technical policies – for example, what can be specified in a UNIX system will be different from what can be specified in a Windows system. Consequently, technical policies are quite often associated with specific devices or classes of devices. 

Policy Formatting
I have found it useful for reference purposes primarily but also for clarity to number each statement in a policy document in an outline format. For instance, a policy statement might be number 1.1, while the associated standards are numbered 1.1.1, 1.1.2, and so on. Separating each standard and policy statement into a new paragraph and number also assists during the long meetings during which the new policies are edited and finalized before submission for approval. 

Adherence to Standards
If it is important for your company to adhere to a standard, such as ISO 17799 or NERC 1300, you may want to number the policy statements to match the corresponding section in the standard document. This will help you to ensure that all parts of a standard have been covered and provide for easy reference during an audit or compliance review. If numbering the policy statements is not feasible, then you may want to consider creating a reference table that correlates policy statements with the appropriate sections of the standard.

Change Management