The four questions you need to ask to balance external collaboration and risk management

In Darkest Hour there’s a scene in which Winston Churchill is almost begging Franklin Roosevelt for the warplanes that they had ordered, and now desperately needed. It got me thinking about collaboration and about how important it can be for gaining capability; and how badly it can go if we don’t assess the new risks that collaborating entails. I’ll refer back to this scenario throughout the post but please note that for the history buffs, I know I’m not being historically accurate.

Collaboration is essential to doing business – I don’t think this is in dispute (if you’d like to dispute it, I’ll happily debate you). What I don’t think gets talked about often enough is how we should think about the decision to collaborate. All collaboration should be cost-benefit based, with the decision predicated on whether the benefits outweigh the risks.

I’ve found that the frame below a useful way to think about the decision to collaborate with another organisation.

There are four basic questions that need answering:

  1. What benefit is there to collaborating?
  2. What new risks does the collaboration expose us to?
  3. Can you effectively mitigate the risks?
  4. Who has the authority to decide whether the balance is right?

1. What benefit is there to collaborating?

The UK needed planes to fight a resurgent Germany – but should they build them, or collaborate to get what they needed sooner and maybe even cheaper?

Stage 1 must be about quantifying the gain from collaboration. Collaboration is always about achieving objectives cost-effectively. If your organisation can already achieve the objective cost effectively, you don’t need to collaborate. Your thesis should be that collaborating will let you will gain access to information, capability or knowledge at a cost that makes the risks of collaborating worth the organisational gain. The deliverable from this stage should be a cost-benefit analysis.

2. What new risks does the collaboration expose you to?

Getting the planes sooner and cheaper gives the UK more capability, and more reserves to buy more capability if they need it – but what risks will relying on the US introduce?

Collaboration will always expose your business to new risks – so stage 2 should be identifying and quantifying them. New risks will principally come from two places –

  1.  The fact that your counter-party will always have better information about what they offer.
  2. The information you will expose about and from your business while collaborating.

To get this assessment right, you should seek input from experts in all areas of your business. Once you have an accurate risk register, and assessment of the magnitude of harm, you can move on to mitigation strategies.

3. Can you effectively mitigate the risks?

The war winning or losing question – if the US doesn’t deliver the planes when we need them, what do we do?

Once you understand the risks, mitigation measures can be defined. Risk mitigation will look to balance the incentives of involved parties, minimise the amount of information leakage, make sure adequate information about service quality is available, and ensure that adequate backup plans are in place. Once you understand your ability to effectively mitigate each risk, you can then make a call about whether to insure against or accept any residual risks.

4. Who has the authority to decide whether the balance is right?

Get it right – and the UK gets the planes and has the capability it needs to defend itself. Get it wrong, and the UK faces a resurgent Germany without what it needs to defend itself. Who had the authority to risk the future of the United Kingdom on this collaboration?

Someone in the organisation will need to accept the risks of a new collaboration. How high in the organisation they are will depend on the impact of loss. If you know who this person is, you should consider their appetite for risk early on and include that in your early go/no-go decisions. It goes without saying that putting together a great case for someone whose’ risk aversion won’t let you move forward should be avoided.

Conclusion

We all collaborate many times a day without thinking about it. When we go across the boundary of our organisation, the dynamic changes. We should be doing it because there is a cost-benefit relationship that lets us access information, capability and knowledge at far below the cost of developing it. Benefits though are only one side, we need to also consider the risks and whether we are able to take those risks on behalf of our organisation. If you keep this frame in mind, you should get good outcomes.

Does this reflect your view on collaboration and how it should be approached? If not, I’d love to hear from you and understand why.

The only four reasons why you should collaborate with another organisation

Collaboration is “the act of working together to produce something”. Over the last ten years it has been billed as a magic bullet, and like so many magic bullets, it has become unfashionable to question why, how and if we achieve value from it. Which I think is a mistake that has eroded our understanding of it, and lead to the current magic bullet view.

In a previous post, I outlined what you can get access to when you collaborate. Just because you can though, it doesn’t mean that you should. There are four reasons that I think make collaboration worth consideration:

  1. You need something faster than your organisation can deliver it.
  2. Developing or acquiring what you need in-house is too expensive.
  3. Your organisation cannot create what you need because of regulations.
  4. You’re looking for the capability to become a customer.

Under any other circumstances, you should seriously question the need to collaborate. Collaborating is a build or buy decision that has to stand up to a cost-benefit analysis. If your organisation can deliver what you need fast enough and at a market competitive price, without violating any regulations, what justifiable reason do you have for collaboration?

The three things you can get by collaborating with another organization.

Collaboration is “the act of working together to produce something”.

It’s fundamentally about going outside your organization to get access to something without having to build it. There are also times when you might not be able to get what you need internally for regulatory reasons, or because the capability to become a customer is a self-defeating cycle if you’re just buying your own stuff.

When you collaborate with another organization, you should think about the gap you are trying to fill in terms of one of the following three things –

  1. Information – facts about something or someone.
  2. Knowledge – the theoretical or practical understanding of a subject.
  3. Capability – the power or ability to do something.

Once you define your need in one of these terms, you’re much more likely to make the right decision about whether you should collaborate, and then to find an efficient supplier of what you need.

Where is multi factor authentication in the 2017 Australian Government Information Security Manual?

This post is going to be a bit dry, it is written to provide an accurate overview of specifically where you can find multi-factor authentication controls in the 2017 Australian Government Information Security Manual (ISM). It is accurate as at the 3rd of March 2017. If you are in a security or IT decision-making role, and are considering whether multiple factors of authentication should be part of your security apparatus, the ISM provides both a minimum standard for accreditation, and guidance that can be used to inform your risk assessment. Each control is contextual, and doesn’t apply to every situation – you should seek a qualified opinion from a member of the IRAP program to ensure that you are assessing the right controls.

The minimum standard is imposed through controls that are listed as “must” for compliance purposes. In areas where some consideration of control vs. ease of access is appropriate, the controls are listed as “should”. What is clear from the ISM is that for system administrative activities, it is not considered acceptable to act without multiple factors of authentication. In some individual user access scenarios though, multiple-factors are listed as “should”. This lessening of controls for end users provides scope for each agency to consider the level of risk associated with access to the system, the level of burden that it is appropriate for users of that system to bear, and the level of operational complexity that the additional factors add.

As always, prior to looking at controls, the grade of information the service will carry needs to be decided. The cost of achieving each higher classification rises substantially, and each successive classification focuses more on access control than ease of access. From a risk perspective, more consideration of whether “should” should become “must” should also be considered. Appropriately qualified security and risk management personnel should be engaged to advise on these matters.

From a pure control standpoint, the controls focused on multi-factor authentication are listed below, each applies to all classifications –

  • 0974 – “Agencies should use multi-factor authentication for all users.”
  • 1039 – “Agencies should use multi-factor authentication for access to gateways.”
  • 1173 – “Agencies must use multi-factor authentication for” – system and database administrators, privileged users, positions of trust and remote access.
  • 1384 – “Agencies must ensure that all privileged actions must pass through at least one multi-factor authentication process.”
  • 1401 – “Agencies using passphrases as part of a multi-factor authentication must ensure a minimum length of six alphabetic characters with no complexity requirement.”

Some discussion of Multi-factor authentication can also be found in the “Access Control” section of the ISM – Principles manual.

All the documentation you need can be found at https://www.asd.gov.au/infosec/ism/index.htm

The 2017 ISM – Controls can be found at – https://www.asd.gov.au/publications/Information_Security_Manual_2017_Controls.pdf

The 2016 ISM (the latest) – Principles can be found at – https://www.asd.gov.au/publications/Information_Security_Manual_2016_Principles.pdf

What access security really is, and the myth of “totally secure”

A good definition of security will let you do two things –

  • Make more objective decisions about how much to spend on security.
  • Sort out who the people who don’t know what they’re talking about (and the liars) are.

So what is security as it relates to access?

Access security is the process of making access cheap for people who are authorised, and expensive for people who are not authorised.

That’s a simple but objectively useful definition. It’s useful because it can be applied simply to every form of access security – armed guards, door locks, IT security, theft laws – it’s universal. With the definition in place, you can move on to a conversation about how expensive access should be, then think about how you invest. Any investment in security should introduce significantly more cost for someone attempting unauthorised access.

In the light of that definition, it’s also easy to see why “totally secure” is a myth. Any form of access means something is now only secure against a certain amount of expenditure.

Next time you’re talking to someone about security and they’re asking you to make an investment, ask them about how much access expense the investment will add for an unauthorised person. Then you can compare it to the cost of what you’re securing. If you can’t make sense of that, you should find someone who can help you can. Any investment in security that doesn’t make unauthorised access many times more expensive than its cost is just the purchase of a warm and fuzzy feeling.

Reducing risk in government contractor engagements by improving information governance

The last two decades have seen a step change in the methods we use to interact with contractors. Generally speaking, the primary means of engagement is now digital. This has brought with it significant reductions in the cost of engagement, and reduced the time to commencement of work. It has also increased the volume of engagements each employee is expected to support, and the quantum of risk associated with incorrect transfers of information. In discussions with many government entities I have found a number of common areas in which expensive problems occur frequently, that I also believe can be substantially reduced by improving information governance around each engagement.

Incorrect version transmittals. In organisations that run large projects, I’ve found that transmittals are still error prone. Large transmittals (lots of documents, or large documents) generally go out as multiple emails or on physical media – paper or digital. When they do, the probability of using an incorrect document version increases substantially and has obvious consequences for the financial and completion timeline of a project.

Provision and capture of as-built documentation. As-built documentation is typically large and held in systems inaccessible outside the organisation. It almost always has changes that need to be captured in a system of record after an engagement. Content is large enough and changed exclusively digitally, so transmission needs to be via electronic medium, or post work updates become very difficult. After an engagement, capture and correct storage of updated as-built documentation is again difficult. The risks are clear, when access isn’t provided and updates aren’t captured effectively, engagements start with incorrect information that leads to variations and re-work.

Capture of compliance documentation. Compliance documentation is a fact of life for contractor engagements. Workcover, insurance, safe work method statements etc. Good contractor management dictates that this documentation should be captured and stored in an organisational system of record and preferably associated with the specific work. Breakdown in this capture process is usually only noticed when there is a project failure. It can often be explained by an over-reliance on email, and failure to follow information governance processes. Mailbox limits frequently dictate that people will archive to repositories that are typically ungoverned and which can lead to a variety of significant liability scenarios.

Proof of work. Proof of work for contractor engagements has gone electronic over the last few years, particularly where it involves small construction or physical maintenance tasks. In some scenarios, inspectors capture photos of completed work, in others, contractors provide photos to prove completion. In each scenario, the problem is the same, the photo is provided, the payment is ordered, everyone moves on to the next project, often without the proof of work being captured in a system of record. I have spoken to records managers supporting legal action who counted themselves lucky for being faced with directories of several thousand photos with descriptive names like “DSCP1101”. The reality is that photographic proof is often lost with the email archive or laptop of the employee who ordered the work.

Ultimately, each of these scenarios can lead to substantial loss, and reflects an information governance challenge that is relatively simple to address. Many of these challenges can be traced to contractors’ lack of access to information governance systems. Manual work arounds and transfers from a system of record to an ungoverned system (ie. email and paper) introduce information risk that can easily be avoided.

Good solutions to this problem start by ensuring that there is a single source of truth for engagement information, and that all staff and contractors involved have access to it. They wrap an information governance framework around the engagement processes, ensuring that when evidence of transmittal, completion, or compliance is needed, it has been captured, is available and its source is known. This is a gap I’ve often encountered within the government organisations that I deal with. Historically this gap has been caused by tool cost and the security status of cloud platforms. Recent changes to the Australian Government Protective Security Policy Framework, and Information Security Manual mean that tools like our own Objective Connect and others are now viable for use by government. If you’re having trouble controlling risks like the ones above, a tool like ours should be on your list to examine.

Collaboration governance and notifiable data breaches – how do you achieve certainty?

The Privacy Amendment (Notifiable Data Breaches) Act 2017 will come into force on the 24th of February 2018. It means that an Australian Privacy Principle (APP) entity with reasonable grounds to believe an “eligible data breach” has occurred needs to report it to both the Office of the Information Commissioner, and the affected individuals, and conduct an investigation within 30 days. Many organisations will fail to effectively service this requirement because their response will rely wholly on meta-data. Effective responses will be made possible via systems that automate the collection of both data and meta-data about content collaboration events involving external parties.

In the lead up to reporting an event, the difference between a notifiable event and the continuation of business as usual, is likely to come down to being able to answer a few specific questions –

  1. What information did we lose control of?
  2. To whom was it exposed?
  3. What is the level of certainty?

In an organisation with automated external governance capture, the answer can look like “we provided x content to y, here are the audit trails and here is the content in its original form”. This answer will likely have a high degree of stability over time.

Organisations with less mature governance frameworks will rely on machine meta-data and interview data. A response from this organisation will have a high degree of ambiguity – “we can see that x accessed y cloud service and uploaded some content that might contain z data”. Three months later, a response even at this level of certainty may be impossible as meta-data logs are routinely overwritten.

Organisations that effectively move towards maturity do it by enabling content-based processes, with tools that make process work more efficient, and capture data and meta-data as a by-product of usage. In the vast majority of cases that I have worked on, control was lost due to the lack of an approved tool rather than by accidental means or malicious attempts to circumvent controls. Once an approved tool is implemented, steps can be taken to reduce access to other tools over time – this will include putting barriers in front of physical media, internet sharing services and email.

Ultimately, good response under mandatory breach disclosure is going to come down to having both the data and the meta-data. If you’re struggling with how this will play out in your organization and you’d like to understand one approach, please reach out to me, particularly if you’re a HPE Content Manager, SharePoint or Objective ECM customer already.

If you’re looking for a good primer on notifiable data breaches, I found the link below from Clayton Utz extremely useful, you can also find lots of good information on the website for the Office of the Information Commissioner.

https://www.claytonutz.com/knowledge/2017/march/take-notice-mandatory-data-breach-notification-laws-to-take-effect-by-23-february-2018