Category: Policies & Procedures

In all my years performing security assessments, and even providing my own policy and procedure service, somehow I have completely missed out on HOW to actually manage the polices, standards and procedures. Yet I have harped on about them incessantly.

Yes, I have mention a Document Management System (DMS) as a way of controlling and distributing documents, but I had never really given thought as to how you would go about maintaining a library of documents that almost all organisation collect over time.

It may not sound like an important subject, until you realise that no policy, standard, or procedure means anything unless it’s the RIGHT one. Is the procedure you’re working from the latest version? Are you in violation of a policy that can lead to you getting fired because you’re looking at a printed copy from 2014? Are you holding your vendors accountable to SLAs in the latest contract?

The first thing I have noticed is that it’s incredible easy to over-complicate the whole thing to the point it’s unsustainable. It must be intuitive for anyone to follow, and it must be easy to manage, or like everything else in security, it will be bypassed.

I would love to hear from true expert on how this is done, but for now, he is what I think is best:

  1. Document Numbering: Have enough information that you know at a glance what the document is, but not so much that it’s 100 characters long. For example;

    * First 2 characters is the company name, or a designation of external (e.g. CN, or EX)
    * Second 2 characters is the document type (e.g. PO = Policy, PR = Procedure etc.)
    * Third 2 characters is the applicable region (e.g. GL = Global, GB = United Kingdom, etc.)
    * Fourth 2 characters is the applicable department (e.g. XX = All departments, LG = Legal, SE = Security etc.)
    * Last 4 characters is the unique number (e.g. 0000 – 9999)

  2. Revision Number:  rX.0 for major release, and rX.1 for a minor release. So the first draft would be r1.0, a slight change would be r1.1, and a complete rewrite would be r2.0 and so on.
  3. Friendly Name: What’s the document title? e.g. “Access Control Policy”
  4. Document Status: One of only 3 things; DRAFT, RELEASED, or OBSOLETE, all self-explanatory

So, for Acme Rockets Ltd., a first draft of a global legal policy on access control would be; ‘AR-PO-GL-LE-0001-r0.1 – Access Control Policy-DRAFT‘, or a rewrite of a vendor contract related to  a firewall managed service procedure specific to the UK would be; ‘EX-PR-GB-SE-0003-r2.0 – Firewall Managed Service Procedure-RELEASED‘

Assuming I haven’t completely lost you, the next step is to work out how to get them into a centralised and access controlled library to which EVERYONE who needs access, has it. Every RELEASED version of the entire policy and procedure set needs to be online and the location of it familiar to the entire company. No printed version can ever be trusted unless the number, name, and status matches (these should be printed in the document header).

Finally, and here’s the real kicker; EVERY document in use in the organisation needs to be entered into a Master Documents Record (MDR) of some sort, and maintained to an extremely high degree of integrity. In theory you could use your Intranet or SharePoint for the central location and an Excel spreadsheet for your MDR, but best of luck keeping that up to date in a large org.

So, am I, David Froud, actually suggesting that larger organisations buy technology to solve a business problem despite my constant warnings not to do so?

Yes, yes I am.

Once again I have chosen a dramatic title to sucker you in. But seeing as it’s PCI related it’s never going to be even remotely exciting.

First; per the title, I’m not actually a QSA any more, but I have been in the trenches of PCI since before there were QSAs. Anyone remember QDSPs? I am therefore reasonably well qualified to write about it.

Second; by “PCI From the Other Side”, I mean that I found myself in a scenario where I was the one being assessed. The remainder of this blog is about that experience. It was truly eye-opening, and I hereby apologise to every client I’VE assessed over the last decade. I only now feel your pain.

But it’s not until you find yourself on the other side of the assessment fence that you can truly appreciate the challenges. I am both a PCI and cybersecurity expert, and even I had a hell of a time putting my organisation through the process. And I designed the infrastructure with compliance in mind!

My first challenge was finding a PCI compliant service provider (SP) who covered the vast majority of the infrastructure related processes. From configuration standards, to AV, to logging and monitoring I didn’t want to do anything in-house. I spoke to several service providers, and found myself guiding THEM in the design of their PCI services! Regardless, they were universally unhelpful, and if I had this much difficulty, what chance does anyone else have?

Even Amazon Web Services does a better job than every SP to whom I spoke. While AWS basically devolve almost every aspect of compliance back on the client, they at least break down the EXACT responsibilities for all parties. Yes, PCI DSS v3.X does a better job of making this a requirement, but it can still be very difficult to get the right information based on a vendor documentation. If you don’t ask the right questions, no SP seems anxious to provide them for you.

The second major challenge was the sheer volume of ‘paperwork’. Policies, Procedures and Standards make up roughly 35% of the PCI DSS requirements, and at least 47% of validation against all requirements involves review of some form of documentation. Even if it’s just a screenshot.

As an assessor, I would give my clients a spreadsheet that tells them what kind of document I need against any given requirement. They would then complete this with the document THEY believe meets the intent of the Testing Procedure. For my QSA I went one stage further and mapped my policies and procedures (including Section numbers!) against the Report on Compliance v3.X template itself.

Now these are Policies that I have mapped against the PCI DSS / ISO2700X/ CoBIT etc. I have even sold them to several clients to help with their compliance efforts, yet it took me several weeks get them where they needed to be. As for the Procedures and Standards, I had to create 24 separate documents to cover everything from Change Control to Vulnerability Management. This was NOT fun, or easy!

Like finding a Service Provider, I had a huge advantage over most people in charge of putting together their organisation’s documentation. If this was the pain I went through, I do not want to begin to imagine the pain for anyone not an expert. [Note: The ‘paperwork’ is critical not just to PCI, but to security in general, and should NEVER be done with just compliance in mind!]

I have written too many blogs about the problems with the PCI DSS to harp on about them here, and there were far more issues I faced than you want to hear about. Needless to say, if the SSC really want to train new QSAs, they should throw out their entire curriculum and put them in the client’s shoes for a day.

95% of them would fail.

Who am I kidding, 95% of CURRENT QSAs would fail, I almost did!

[If you liked this article, please share! Want more like it, subscribe!]

I really should give up being surprised when the most basic of information security fundamentals are performed poorly, but this one constantly amazes me. I guess it’s no different than a doctor being surprised at smokers, or the police surprised at repeat offenders, we can accept as common sense what others perceive as new concepts.

Education and Training is so important that I have listed it as one of The 4 Foundations of Security, along with Management Buy-In, Policies and Procedures, and Governance. The fact is that education is the best and cheapest way for an organisation to implement the desired organisational culture, and distribute the policies and procedures in a manner where they actually understood and followed.

The intent of PCI DSS Requirement 12.6.x is to ensure all employees are trained in their security responsibilities as they relate to the protection of cardholder data. That’s it, just cardholder data, so you can obviously ignore every other form of sensitive data in you environment, right? What about your financial data, or intellectual property, or personal data? Unfortunately you cannot go above and beyond in PCI unless it relates to the protection of cardholder data, so with the exception of perhaps frequency of training, there’s not a lot you can do here.

That’s for PCI though, for your BUSINESS it’s a very different matter, and there is a lot you can do to add true benefit across the organisation. Not just in terms of security either.

The mistake most organisations make is the assumption that security education and training only refers to things like keeping your passwords secret, or not lending out your swipe cards. Yes, training includes these things, but it starts with a thorough coverage of all relevant policies and procedures. I say relevant, because you’re not – for example – going to train your sale team on the proper implementation of firewall configuration standards.

Training is not just some paperwork exercise during on-boarding, then an annual obligation thereafter, it’s the way you bring someone into your organisation and have them up to speed and productive in the fastest time possible. It’s also how you begin to instil the corporate culture (i.e. your policies), and how you ensure that they are performing their duties in-line with standard practices (i.e. your procedures).

Once they have the basics, you can move on to role specific training, and then, if you’re REALLY doing this properly, you will have the individual job specifications detailed to the point where anyone being on-boarded can step straight into the leavers’ shoes with barely a backwards step.

That’s really the whole point; security awareness training is NOT just a compliance obligation, it’s an integral part of your business continuity and knowledge management processes. It can be the difference between a constant reinvention of the wheel every time you have a mover or leaver, and uninterrupted growth. You may argue that this is more than just security awareness education and training, but I will counter that without proper knowledge, there IS no security.

While I agree that every time there is a staff change, the training itself should be reviewed and revamped as appropriate (preferably by the person bringing the new pair of eyes to it), NO-ONE who is just starting should have to work out anything for themselves on how to perform the function to which they have been assigned. At least to a minimum standard. Unless of course it’s a brand new role, in which case they will be responsible to develop and document everything necessary to replace themselves in time.

Too often this is seen as making yourself replaceable, but if you can’t be replaced, how can you move up, or even across?

To perform security awareness and training properly, follow these steps:

1. Like access control, the best way to begin developing a good training program is to properly define the requirements, first at a ‘corporate’ level (everyone), then at a more granular ‘role’ level (sales, systems admins. etc.), and finally at an ‘individual’ level.

2. Once this matrix is complete, combine this ‘paperwork’ into an online delivery mechanism which is a combination Document Management System (DMS) and distribution method. That’s really all online training software is; content management.

3. Run everyone through the program, regardless of tenure, and regardless of when they last took it. Track all ‘signatures’ (an online ‘I Accept’ will suffice).

4. Run training again at a minimum annually, but preferably every 6 months. A good balance is full course annually, and Top 10 Things to Remember at the 6 month mark.

5. Throughout the year, use this distribution method to announce major changes to policies and procedures, as well as ‘zero day’ threats (new phishing techniques for example), for significant changes to relevant compliance regulations or laws, and any ad hoc matter for which you require – for liability purposes – a written confirmation of acceptance.

 6. Provide a robust feedback loop and standardised forms for all personnel to request policy / procedures changes, or to create new ones.

I’ve not touched here on the actual content of the security training, it’s too organisation / sector specific, but there are certainly some basics (101 stuff as the Americans would say). However, the development of a comprehensive and sustainable training program requires specialist skills and experience, so make the effort and expense, there’s not one investment you can make that has a greater ROI.

Of the roughly 400 separate requirements in the PCI DSS, 46% of them require the review or examination of some form of documentation. From policy, to procedure, to configuration standard to diagram, a very significant chunk of achieving PCI compliance starts with paperwork.

How is it then that in the 10 years I’ve been performing PCI and PCI-esque assessments the ‘paperwork’ is almost invariably the last thing to close? I’ve seen large organisations get centralised logging in place before they managed to get their policies and procedures in order.

In Want REAL Information Security? Start With Your Policies I have already gone into why organisations should take polices and procedures more seriously, so I’m not going to repeat myself. But I will just say now that if you didn’t start your project to formalise your policies and procedures at the beginning of your assessment, stop, go back, and start there. A good QSA will fail you for crap policies just as quickly as they would for lack of encryption on stored card holder data.

All too often the client response to a request for documentation is to provide a handful of polices taken from the internet with the company name changed, but no effort whatsoever to customise the content in line with reality. Procedures are virtually non-existent, everything is in unprotected Word docs, several years old, and in no way standardised. The look on the faces of those being asked to provide just the location of the official copies is usually one of confusion, or worse, blank incomprehension.

The worst thing you can do is hand your QSA a bunch of crappy docs and say “You tell me what’s missing.” It does not work that way, and all you’ve done is thoroughly irritate someone who should be on your side. It is YOUR job as the client to tell the QSA which documents and specific language YOU think meets the intent of the DSS requirement testing procedures. The best way to do this (if you don’t have access to a GRC tool with DMS built-in, see below) is just to start with the DSS on a spreadsheet and map your existing documents to it. Your QSA will tell you the gaps, which gives you the necessary action items to begin your remediation.

Here’s the one I give my clients, help yourself; PCI DSS v3.0 – Document Mapping Matrix

Other stuff:

  • Policy Content – In terms of policies, procedures and standards, these are the major headings I generally expect to see; PCI DSS v3.0 – Policy & Procedure Checklist.
    o
  • Document Management System (DMS) – This does not have to be a major expense, a folder on an intranet share will suffice, but the point is to have a centralised location to place all of your latest approved documents. They should however have access control mechanisms in place to ensure only those with a real need to see them, can. Some of the more elaborate DMSs will take care of version control, ownership, review cycles and so on, as well as automated mappings to regulatory compliance regimes like PCI. Choose what’s right for your business, and look at the Governance Risk & Compliance tools that may have this built-in.
    o
  • Pre-Packaged Templates – There are many organisations that can offer pre-packaged policy templates, but none that can provide pre-packaged procedures. Best practice policies are numerous and can be customised to suit your business, but procedures are written by your organisation and are necessarily specific to it. Don’t buy anything claiming policies AND procedures out of the box, and don’t buy anything specific to PCI. Cover your business, and if you have to spend money to get your ‘paperwork’ together, focus more on expert guidance. Avoid policies that match the next two points.
    o
  • Monolithic vs. Modular – It is generally best to have each of your separate policies as stand alone documents with their own version history and ownership, a single policy document is very hard to maintain.
    o
  • PCI Relevance – The phrase ‘card holder data’ should appear only once, maybe twice, in all of your policies; in the Data Classification Policy. Every other policy refers to the classification in which card holder data was contained (e.g. Highly Confidential).

Like everything in security, getting policies right is not easy, but it is simple. There are many people out there who can help you if you don’t know where to start, and this is not something you should do half-arsed.

[If you liked this article, please share! Want more like it, subscribe!]

I am constantly surprised and disappointed that the Policy Set (policies, standards, procedures, and guidelines) aren’t taken more seriously. They are the blueprint of your corporate culture, the single most important aspect of your security program, and by far the easiest and cheapest things to put together (in terms of capital costs anyway).

Even a ‘controls only’ standard like the PCI DSS is roughly 40% ‘paperwork’, but, with the possible exception of the risk assessment, remains the most common tick-in-the-box exercise of them all. Which is a shame really, as it should be enough that thieves want to steal your data, to make things worse by not preventing your own employees from virtually giving it away is just plain dumb?

A Policy Set generally consist of 4 main components:

  1. Policies – the dos-and-don’ts of your entire organisation and use language like will / must / shall. e.g. Your authentication policy states that you; ‘MUST use strong authentication for access to systems containing data above a certain classification.’;
    o
  2. Standards – A very detailed document that explains exactly HOW something is to be configured. From operating system hardening guides to firewall rulesets. e.g. the details the actual password elements that constitute ‘strong’ (7 characters, alpha-numeric, change every 90 days etc.).;
    o
  3. Procedures – describe HOW you implement the policies in YOUR organisation. They are detailed, ‘living’ documents that prevent the constant re-inventing of the wheel when faced with performing standard functions. e.g. this is how you long into X system using 2-factor authentication.; and
    o
  4. Guidelines – The only non-mandatory element of the Policy Set, they provide good-practice guidance on how to implement a policy or standard requirement. e.g. For passwords, don’t use birthdays, don’t use names of children, consider a pass-phrase instead etc.

However, you can have the most polished documentation ever, and still completely miss the mark. It’s not about the paperwork itself, it’s about the enforcement of what’s IN the paperwork. A policy is only ever as good as the understanding of it, and the adherence to it.

Unfortunately, this is where most organisation fall down, and one or most of the following challenges apply:

  1. Policies not in-line with corporate culture or day-to-day business process – Policies should be owned, and even written BY the CEO / BoD. Who else is responsible for the culture, direction, and future of an organisation more than them? Too often this is delegated to departments or individuals without the necessary authority or experience to perform the function properly. A document coordinator MUST be a subject matter expert;
    o
  2. Undocumented procedures result in numerous (usually unintentional) breaches in policy outside of formal exception/variance processes – Just because a policy is in place, does not mean everyone knows how to implement it. Every department in an organisation is responsible to describe how each and every task is accomplished. Without procedures and standards, policies can become unenforceable, and every new employee has to reinvent the wheel every time they want to accomplish what should be a standard task;
    o
  3. Policies are undistributed, unenforced, or mis-understood – Just because you HAVE policies, or even procedures, if no-one knows where they are, what they mean, or how to measure against them, they are just pieces of paper. Security Awareness Training programs should start with a comprehensive look at ‘role-relevant’ corporate policies;
    o
  4. Poor document management or lack of integration with formalised training mechanisms – Without a robust document management system, it’s very difficult to both maintain the integrity of the Policy Set, and very difficult to distribute and enforce it; and/or
    o
  5. No feedback or measurement processes – Per the old misquoted cliché; ‘you can’t manage what you can’t measure‘, unless policies are seen as living documents with company wide feedback mechanisms in place, they can rapidly become obsolete.

I do not use the word ‘recommend’ lightly, but I HIGHLY recommend that before you implement ANY aspect of your security or compliance program, you get your Policy Set in place. At the VERY least do this in parallel with a risk assessment and business process mapping exercise.

While most high profile breaches focus on what went wrong technically, I can almost guarantee the original failure was one of education in the most basic of all security foundations; policies, standards, and procedures.

[If you liked this article, please share! Want more like it, subscribe!]