Thank you for reading through this and as I had mentioned earlier, this is a series. This article is the next in the series. Your feedback means a lot and I appreciate the comments coming my way. In case you have missed the earlier articles, the links are below.

Article 1 – http://arrka.com/index.php/2017/07/12/exploring-the-ciso-role-especially-for-the-smb/

Article 2 – http://arrka.com/index.php/2017/08/13/smb-ciso-series-article-2-going-digital-what-dangers-are-you-walking-into/

A policy document, for all practical purposes, is a statement of intent of the person/ group signing / approving the policy statements. The policy document is simply a list of statements which implies “This is what we want to implement and follow in our organization” and then come the Procedures, Baselines, Standards. All the follow-throughs are essentially a derivative of the intent and are the ‘How’of the Policy Statements.

There are four pillars to building and rolling out a Policy, and each of them needs to be nurtured well to have a fairly adequate roll-out and maintenance. There is no such thing as “Successful” and “Unsuccessful” roll out. This is not a software product, this is your intent and what you want to do. There is no success/ failure here, only risk management and the degree of managing risk. And so we come to the pillars required.

– Understanding and Acceptance of Risk

We need to know what our risks/ threats are and which are the ones we cannot control. E.g. we becoming a target for getting hacked is something we cannot control. What we can control is what we do the delay getting hacked and if we get hacked how will we respond.

– Governance Structures

For any policy rollouts, it is important to have a Governance structure and also an owner for Information Security. This can be an outsourced person/ company as well as an in-sourced person.

– Clear Communication

The stakeholders and owners must clearly communicate their intent across the organization by written & oral communication as well as with their actions. Most of the policies go for a toss because the management/ stakeholder team in a quest to get something done quickly, asks the staff to bypass the security protocols. This should be avoided by having a process built which allows for Emergency actions and the Protocol to do so.

– Monitoring

Monitor the progress, awareness of staff continuously. Sit in on roll-out programs to get a feel of the seriousness, and have KPIs for reporting on roll-out levels. Also set up an Internal Audit program to have an independent review at least twice a year, if not more, to get a sense of what is really getting implemented and is the true picture reflected in the KPIs

Around the above, we need to define

Policies

Statement of intent and clear unambiguous statements are required. The statement is always a should/ shall/ will, this should be something that we want to implement. Anything which is a consideration, and has a maybe, should be kept separately for reviews and at best are guidelines and not really policies. All policies should allow for exception approvals and the exceptions/ deviations need to have a tracking mechanism. All policies also always have an Issue date, Effective Date and an Expiry Date. Before the Expiry Date, the Policy should be reviewed and updated as required to maintain consistency with risks that the organization wishes to manage and mitigate.

Procedures

These are specific steps and instructions on how the policy has to be implemented. The procedures are made for technology assets/ devices (and specific to each), for processes which manage the Governance structures/ Audit / Reporting etc, and details documentation requirements for say the background checks for people in sensitive / confidential roles.

Baselines

These are the minimum security rules that we want to apply (as per policy) on the technology devices like network equipment, firewalls, IPS, other security equipment, servers, PC/ Laptop/ Mobile/ Tablet, Applications, Databases etc.

Standards

These are standards that we want to work in. Like we will use all Ubuntu Linux on Servers OR we will use Mysql as database and so on. We can even specify the versions to be used so that anyone installing any software OR buying any hardware has to adhere to the same standards everytime.

The list of policies typically required are as below

  • Security Organization
  • Physical Security
  • Logical Access Controls
  • Password Security And Controls
  • Network And Telecommunication Security
  • Application Software Security (Includes System Development And Application Management)
  • Program Change, Version Controls And Patch Management
  • Business Continuity Management / Disaster Recovery Planning
  • Data Privacy Policy
  • Supplier Relationship Review Policy
  • Electronic Mail Security
  • Backup And Recovery
  • Internet And Intranet Access And Security Policy
  • Operating Systems Security and Database Security
  • Incident Response And Management
  • Third Party Security
  • Asset Management
  • Web Server Security
  • Human Resource Management/ Personnel Policy (Covers Punitive Actions, Training And Personnel Security)
  • Firewall Policy
  • Use Of Cryptology
  • Virus Protection, Mobile Computing And Teleworking
  • Desktop And Laptop Security Policy
  • Audit And Compliance Policy

Next article, we will explode Step 2. Create the Security Architecture on the basis of the Policies we defined.

Till then, stay safe and if you need emergency response/ help, shout out to

Sameer.anja@arrka.com

https://www.linkedin.com/in/sameer-anja-8127851/

twitter: @sameeranja

The earlier articles are at

Article 1 – http://arrka.com/index.php/2017/07/12/exploring-the-ciso-role-especially-for-the-smb/

Article 2 – http://arrka.com/index.php/2017/08/13/smb-ciso-series-article-2-going-digital-what-dangers-are-you-walking-into/