Information Class Warfare part V

Information Security Process: Repeat

August 30, 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.

Repeat, yes, more than just to keep you as a security professional relevant to your employer, but also, repeat at sporadic intervals.

Perhaps this is the most important step, but all of the previous steps should be repeated.

Classification: Revisit your information classification document at least annually to verify that types of information can be added or removed. I have found that the levels of security and access rarely change, more likely that some services have been added or removed in the past year, so the information associated with those products needs to be added to the scope of your security planning or removed.

Securing Devices: These documents should be revisited more often, a scheduled review should be done at least every six months, but they should also be revisited every time a new vulnerability is released for the various systems or networks to verify that adequate controls are in place to mitigate a loss and that security is still at the same levels before the vulnerability was known.

Auditing procedures are generally an ongoing activity, but the guidelines and tools should be reviewed at least annually to see if there are better ways to make the job of auditing easier.

Education for each employee should be part of the on-boarding process, with static links pointing them to useful information specific to their job and a time should e set aside to visit each team at least once a year to see if they have any new issues they wish to address. Short fifteen minute meetings do not impact productivity and longer detailed questions can be answered outside of the meeting scope.

I hope this short series of articles was of use to you, these are some general principles that I use every day as an information security professional.

.wdnii.

© 2013 Norris Proprietaries Inc.

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.