Information Class Warfare part II

Information Security Process: Securing (policies)

August 8, 2013

Information Security like all relationships requires time and effort. I use a security management system which works well for the companies I have secured and maintained. Classify, Secure, Audit, Educate, Repeat. Not a memorable acronym, but a very valuable path to cycle through. Each iteration has made my companies better prepared for the inevitable attacks and recovery easier and faster.

I cover securing information devices and paths in this article in a general way, though I can provide more specific resources.

Securing is a multi-part process, first is taking the original classification of critical systems and information paths and using those to derive specific security policies for each type of device. A security policy should state why it exists, and which pieces of the organization it is trying to secure. Also, and while seeming trivial a date, revision history and revision number is useful.

Each security policy should list the types of networks, devices and data that are included and excluded. For example, a machine which runs DNS (Domain Name Service) externally will most likely have different restrictions from a machine which runs DNS internally. The same with routers, internal routers may have different types of restrictions and required processes than internal routers.

A security policy should list the roles and responsibilities of the system, the information and/or the people who administer and use that system and/or data located on that device. Some systems are critical and the business will fail if those systems are impacted either with a security breach or natural disaster, so some security policies require a business recovery plan for those systems to be back online. This can be done via an active / active solution so the system and data recovery will be without interruption. A hot standby solution provides usually a short interruption which is usually considered not to impact any revenue generation. A cold standby site is another solution, where a copy of the data is kept and depending on the requirements usually the site can be back online in minutes to hours. The least expensive solution is to have off-site backups, where an entire site can be rebuilt from scratch, but the downtime can be quite extensive.

A security policy should list the authoritative documentation for the systems and information being secured, such as any relevant technical books, Internet RFCs, and vendor documentation. You should also reference other relevant security policies and mention that they should also be used. This is the easiest section to write.

My security policies include examples of configuration files and which sections of those files are required to be used, how the program should be run, such as the user and group designations, the user and group ID numbers and even the location on the file system where the programs should be located.

Finally, a section stating which audit procedures will be used and what type of external controls will be used around this type of system. Again for a DNS server this can mandate where the log files are written and how often the system is audited.

Overall though, my philosophy of security is that the information provided needs to be available and accurate when needed. So, a clear link from the data or information categorization needs to be linked to the consumers that use each resource and how these security procedures allow those consumers access to the correct information, but do not allow the information to become corrupt, or allow the consumers to become compromised or allow the consumers to compromise the data for any valid use.

.wdnii.

© 2013 Norris Proprietaries Inc.