Document and Review

2 Comments

It’s unlikely that you will read a more dull and despairing title for a practical blog series than “Document & Review”, and there is a high chance that you will even consider skipping this one. If you do, however, you will be missing the most foundational aspect of your entire information security programme. Without documentation primarily of Policies, Procedures and Guidelines, you have nothing to build your grand information security plan upon. Nothing to reference, fall back on or even educate people with.

Neil Postman, American author, educator, media theorist and cultural critic, summed it up:

“The written word endures, the spoken word disappears.”

If you want to build for the future, you must ensure your message, whatever that might be, endures over time and is easily understood and referenceable throughout its lifetime.

You may think this is obvious, and everybody knows there has to be documentation, as who hasn’t heard the refrain, “it’s in the policy, go read it!”? That said, subsequently pointing towards a meaningful policy document, procedure, or guideline only sometimes produces the results intended. Policies are overly long and descriptive. Procedures either repeat the policy or don’t exist, and the story is similar for Guidelines.

So, dear reader, here is the low down on what each of those terms means and their relationship to each other, laid bare and thoroughly before you:

The Policy

The policy is a high-level document that, after its first 6-12 months of existence, won’t change very often, perhaps every 3-5 years.

It defines the requirements of people, departments and the organisation without specifying the technology or specifics needed to make it happen. For example, here is a statement from a poorly written policy about email security:

“All email transmissions must be protected using the TLS 1.3 protocol to avoid unauthorised interception.”

A better policy statement would be:

“All email transmissions must be protected to avoid unauthorised interception.”

It is a simple change that gives the IT team the choice of a method of securing email that makes the most sense for them. Such policies (and, to a greater extent, the security team as a whole) are technology agnostic, focussing the policy on outcomes and not delivery methods.

Finally, for policies, focus on clear, understandable language that does not use TLAs* or other jargon; policies are designed for as broad a readership as possible and help support educational activities.

The Procedure

A procedure should follow naturally from the policies it supports in that it takes the required outcomes as laid out in the policy and then defines how it is to be achieved. For example, the definition of TLS 1.3 is precisely the information described in the procedure from the above example. Therefore a procedure has a more frequent update cycle, i.e. whenever technology or working practices change.

It’s important to note that “Policy” and “Procedure” are often used interchangeably, yet nothing could be further from the truth. A policy does not state how something is to be achieved, merely that it needs to be achieved. Additionally, a policy may be supported by multiple procedures.

The Guideline

A guideline is a document where the security function can get involved in the technology! It describes a best practice for implementing email. It may well define what version of TLS should be used along with other information about hardening the email server and will inform the reader accordingly. It does not have to be adhered to, and it is not mandatory to follow the guidance there. Dependent upon the culture of the company and the relationship between the security function and the rest of the company, it may also be defined as a Standard. In contrast to a guideline, the standard is a mandatory requirement and establishes minimum expected requirements for the activity/services it supports. A guideline and a standard may be used interchangeably, while the intent and adherence to them are different.

Good Practise

As you might expect, there are some good practices when managing this kind of documentation that should be adhered to:

Review Schedule

Fix a schedule and adhere to it. Every document should be reviewed at least once a year or whenever a significant change in technology, process or even culture occurs. Out-of-date documentation can slow a business down, inhibit innovation and mark the security team out as gatekeepers.

Version control

Always have version control, formal sign-off procedures and clear ownership and accountability of every document. It is an overhead that ensures any audit or review is passed with ease and warrants that the documentation is up to date and, more importantly, relevant.

Distribution

Policies should be made available to everyone. Liaise with the HR department, include them in the staff handbook, post them on the intranet and reference them accordingly. Procedures and guidelines will have a more limited audience, but make sure that the audience knows where they are.

Approvals

These documents should be approved at the appropriate levels, depending on the work environment. However, as a rule of thumb, policies should be approved by company leadership, procedures by department heads and guidelines/standards by the senior technical lead. In this way, there is a clear ownership hierarchy, and the documents create a support structure building upwards.

This sounds like a lot of work…

It is, especially in the early days of setting the work programme up, but its importance cannot be emphasised enough. Without these foundational documents, there is no linchpin to define and guide current and future activities and no frame of reference describing how individuals and the company should behave and work. Finally, there is no way of proving that the security function is meeting its goals and objectives as approved by the company leadership.

Define what you do and ensure your message will endure.

When Auditors Attack!

Leave a comment

Although I am not a formally qualified auditor, I have had a fair amount of experience of carrying out audits and risk assessments in met various roles towards becoming a CISO. I have also been able to present on the topic and have articulated many of the unique challenges faced by auditors and audits alike.

Reading about auditors on social media, articles and LinkedIn is never a pretty affair, and there is rarely any love lost between them and those posting about them. For instance, the QSA who asked for (amongst other things) a list of usernames and plain text passwords. This auditor then doubled down when pressed, accusing the auditee of ntrying to hide a poorly maintained system.

A similar thing happened to a (barely adequate) friend of mine recently, when his auditor reported a finding that “users have read access to the Windows System32 folder” flagging it as a high risk. Even Microsoft stated that this is how their operating system works, and under “normal operation” cannot be changed. My (barely adequate) friend does not run nuclear power stations, by the way.

And attack they will.

Pushing back against these decisions in a formal manner is the only approach you can take; remove the emotion from the conversation and engage as soon as possible, even if it means potentially derailing the audit for an hour or so. If you are able to get team members to do research on the subject, or call in recognised SME’s, then all the better, but establishing the facts early is important. The longer the matter goes on though, the harder it is to resolve.

If that fails, wait until the report or draft comes in. This is an opportunity to formally respond and present evidence to the contrary. This response should be sent not just to the auditor, but also the company they work for (i.e. up the chain of command), as well as other stakeholders such as the clients that commissioned the audit. Their input is important as they are the ones both paying for the audit and with the most vested interest in its outcomes.

Finally, getting everyone involved around an actual table (difficult at the moment I know, but a videoconference will do the trick too) is the last course of action. Hopefully having line management, client/stakeholder, SME’s etc facing off will produce a more amenable result. Don’t expect it to disappear though, perhaps just be downgraded to medium or low.

Being an auditor has a complex dynamic. Third party auditors need to show value to whomever is paying the bills and can sometimes extend the scope or severity of issues to show “value for money”. They can also, ironically, be risk averse and not stand down for fear of being accused of wasting time and a subsequent law suit. An auditor is also trying to be an expert across multiple disciplines at once, as well the one of actually being an auditor, so there are always going to be knowledge gaps. Acknowledging that is a huge step to being a better auditor, and taking time to do independent research on topics you might have not understood as well as you have thought is vital.

For me, auditing/risk assessing was always an opportunity to help the people being assessed; this was a skill as well as a level of emotional intelligence that was shown to me by an ISO 27001 auditor in India, someone I remains friends with after over 12 years. That two-way engagement has been vital to establishing trust and subsequent transparency during audits, and has resulted in better quality findings and a willingness to address them.

Worst case, when it comes to an auditor that won’t back down, you can always just be Accepting the Risk and moving on with the day job.

(TL)2 Security has experience is risk assessment and audit across the security organisation. From a high level risk and gap assessment through to advisory and support services on meeting various certification audits, contact us to find out more.

Busy Doing Nothing?

Leave a comment

When you are faced with managing third-party risks, it can feel like a Sisyphean task at best. Even a small organisation is going to have  20+ third parties and vendors to deal with, and by the nature of a small business, absolutely not a full-time person to carry them out. As an organisation grows, at the other end of the extreme there will be many thousands of vendors and third parties in different countries and jurisdictions; even a large team is going to struggle to deal with that volume of work.

In The Lost CISO this week I talk about how to manage a third-party risk management programme from the perspective its sheer volume of work.

The key to dealing with this volume is, of course, to take a risk-based approach, and consciously decide to do nothing about a large proportion of them. It sounds counter-intuitive, but then a risk-based approach to anything can seem counter-intuitive. (Why would you “accept” a high-level risk for goodness sake?!) In this case, you would quite literally be putting some effort into deciding what not to do:

We’re busy doing nothing.

Working the whole day through.

Trying to find lots of things not to do.

Busy Doing Nothing, written by Jimmy Heausen-Van & Johnny Burke

This means your best approach is to filter who you absolutely must assess, who you should assess, and who can be reasonably ignored. In theory, the last group will be the majority of your third parties. How you filter is of course down to what is important to your organisation, industry, clients, the data you hold, the physical location of your environment (office or hosted) and any other criteria you can consider. Ultimately, it is what is important to your organisation, not what is important to you as a security person. Why? Because if security has the final say, there is a potential for a conflict of interest and the limiting of the organisation to operate effectively and efficiently. Here is a sample list of criteria you can sort your third parties by:

  1. Do they have access to our client’s (or our client’s customers) confidential/sensitive data?
  2. Do they have access to our confidential/sensitive data?
  3. Do they have data access to our IT infrastructure?
  4. Do they have physical access to our premises?
  5. Is our organisation reliant on their services being available at all times?

Inside each of these selected criteria, you may wish to refine further; in answer to the question, think “yes, but…” and you may find a particular vendor does not make your list as a result.

Congratulations! You have now hopefully reduced your third-parties needing to be assessed by hopefully about 80%. If that is not the case, go back to the beginning and validate your criteria, perhaps with business leadership themselves, or (ironically) a trusted third-party.

This may well still leave a formidable list to get through, so there are some more tricks you can use.

When assessing some of the larger third-parties (think Apple, Google, Microsoft etc.), you may wish to accept their certifications on face value. The chances of getting a face to face meeting and tour of the facility, whilst not impossible, are remote, and very much dependent upon how much you spend with them. The more reputable vendors will be transparent with their certifications, findings and general security programmes anyway.

You can then use this filter again with the slightly less well-known vendors but include a handful of questions (no more than fifteen) that you would like answered outside of certifications.

The smallest vendors with the least formal certification and publicly available can be presented with a more detailed set of “traditional” third-party risk questions. Make sure they are relevant, and certainly no more than 100 in total. You are better off getting a good idea of most of the vendor environments from a returned questionnaire than you are a perfect idea of a handful of environments from a barely returned questionnaire. The idea here is to get a consistent, medium level view across the board in order to spot trends and allocate your resources effectively.

Still overwhelmed with sheer volume? If this is the case, look to a three-year cycle rather than an annual cycle. You can reduce the workload by up to two-thirds this way, but you may wish to consider that some vendors are simply too crucial to have on this kind of cycle.

So all that is left is to ensure all of this is carefully monitored, tracked and managed. For instance, what are you going to do with a vendor that doesn’t meet your standards?

And that, my friends, is for another blog.

(You can download a sample third-party security questionnaire from the (TL)2 security Downloads area. There will be more templates arriving soon that you can download and use for yourself, or you may wish to contact (TL)2 if you would like some help and support in creating a third-party risk programme.)

 

 

The Power of Silence

Leave a comment

Not so many years ago in the dim and distant past, the very first full length public talk I did was called “An Anatomy of a Risk Assessment”; it was a successful talk and one I was asked to present several times again in the following years. Below is a film of the second time I presented it, this time at BSides London:

My presentation style left a lot to be desired, and I seemed unable to stop using note cards until almost eighteen months later despite me not using them for other talks I gave! (Top speaking tip folks, never use printed notes when speaking, it conditions your mind to think it can only deliver when using them.) But that is not the focus of this message.

One of the pieces of “anatomy” that I spoke about in terms of risk assessments was the ears. The principle being that since you have two ears and one mouth, when auditing or assessing you should be listen twice as much as be speaking. This is important for two reasons, the second of which may not be as obvious as the first:

  1. If you are assessing someone or something, you should be drawing information from them. When you are speaking you are not gaining any information from them which is a wasted opportunity. As a consequence of this therefore,
  2. There will be periods of silence which you must not feel tempted to break. Just as nature fills a vacuum so a human wants to fill a silence. Silence therefore will encourage the target of the assessment to open up even more, just so as not to feel awkward!

Interestingly, after my very first presentation of this talk, a member of the audience asked me if i had ever been in the Police Force. “I haven’t” I replied.

Well, some of the techniques you just described are exactly like police interrogation techniques, especially the silence. I should know, I used them every day!

Flattered though I was, I did become a little concerned! Was i taking this risk assessment malarkey a little too seriously? Was i subjecting people to what amounted to an interrogation?

Obviously this was not the case, but it occurred to me that in the many books i have read on risk assessment and audit, never is the softer side of the process covered. We tend to focus on the technology, or the boxes that need to be ticked, when actually we can simply sit back and let others do the talking. I also employ humour very often to help people relax, and even do it when i am on the other side of the table too. It can make a gruelling and mindless activity far more engaging and allow you to connect with the person on the other side of the table more effectively.

It engenders trust.

You can apply many of the techniques described in the presentation in your daily work lives, especially when on a discovery programme or wanting to get to the bottom of an incident. In fact, I can’t think of anything easier than having a (one-sided) chat with someone and getting the assessment completed.

Or as Will Rogers, actor and vaudeville performer in the early 1900’s put it:

Never miss a good chance to shut up

On another note, look out for a new series of YouTube films coming from me in the next few weeks.

I give you, The Lost CISO

Less is sometimes more; InfoSec’s role in the business

1 Comment

Funny-and-Lazy-Animals-7-300x229I read an excellent article the other day from a LinkedIn reference talking about how laziness can be an effective approach to productivity. It dispelled the myth that “leaning in” when applying yourself to your job isn’t always required to do a good job. There is no need to get up at 04:30hrs to get your morning yoga done before getting to the office at 06:00 and working through the next fourteen hours. it even makes mention of an old Prussian army management matrix that made use of this concept. It reminds me of a Bill Gate’s quote (although it sounds like Steve Jobs!):

I will always choose a lazy person to do a difficult job, because a lazy person will find an easy way to do it

When put like that it sounds right, and yet the concept of using a lazy person seems counterintuitive. Perhaps we should replace lazy with “busy”, or “time poor”, but I think the point is well made nonetheless.

It reminded me of when I wast first put in charge of an information security project to ascertain the organizations level of exposure to personally Identifiable Information (PII). There had been a number of high profile breaches in the media, and the leadership was concerned about how many records we had access to and what we were doing about it. My approach was to work with a very talented team of junior infosec professionals, and we came up with an amazing spreadsheet that tracked every facet of what we thought we might need with, with macros and reporting buttons, lovely color scheme etc. We even tried to make it as friendly as possible as the trick up our sleeve was that we would be asking 95% of the organisation to fill this in themselves (and therefore saving on high labour costs to get this done). The other 5% were the very risky ones we already knew, so they got a personal visit from us to make them feel really special!

After a month of pushing, chasing and cajoling, our completion rate was something like 13%, and we were just a few days away from our deadline. Senior management were not happy, and demanded a full review. The career dissipation light started blinking in my peripheral vision.

We were trying to be far too clever for our own good, far too detailed, we wanted to cross EVERY i and dot EVERY t, whatever the cost to the project and the business. We were detail oriented and were going to get the most accurate report this company had ever seen. Except we didn’t. I was clearly told in no uncertain terms that I had completely misunderstood the business, how busy they were, how finite detail wasn’t what was at stake but getting a good idea of the scale of the problem was, and also to understand that people are generally doing their best to protect the company and were not in the habit of hiding the sort of activities we were doing our best to uncover.

We reduced the 154 question spreadsheet to 10 questions, some of which were voluntary. They were the the most important questions we had to ask, and we subsequently got the data we needed in a little over three weeks for roughly 97% of the organisation (you can’t help some people unfortunately). I managed to keep my job.

Perhaps it is our backgrounds in audit and compliance, but we infosec professionals love our checklists, our questions, our matrices and black and white answers to really drill down to the finite detail. That is not to say that at times they are not important – a good penetration test does need to be detailed and very complete, but that is mainly because the expectation of it being so. It wouldn’t surprise me though if 20% of a pen test uncovers 80% of the vulnerabilities. Vendor security questionnaires, risk assessments, audits, project or team reviews etc., can all potentially be done just as effectively with an element of brevity. Understanding what is important to the business and not to the security function is key here. If infinitesimal detail is important to the business then by all means go for, just ensure that is what the business really is after. most of the time they just need a reasonable picture.

Creating barriers to the successful adoption of security practices by using fifty page reference documents, or encouraging people to work around a security risk because doing the right thing involves sign off from six different gatekeepers is not a recipe for success as it puts the organization in direct opposition to the security function. By making sure that checklists and questionnaires are focussed, relevant and to the point will only encourage people to adopt the security measure that matter because there is clear benefit for a small amount of input.

We have all got better things to do with our time than collate thousands of questions that we have insisted are answered in order to ensure that the ultimate security objectives have been met. In some instances there may be value in that, but in the majority of cases I would wager there is none.

And besides, the rugby/cricket/baseball* match is on this afternoon, so we need to leave early to catch the game.

*Delete as appropriate. Just don’t add football.