Defining your Cyber Problem - BrisSEC19 talk

This was my BrisSEC19 (AISA) '10 min talk' – part of the Cyber 101 series during the conference on 29-Mar-2019.

Conference link: https://www.aisa.org.au/Public/Events/Conferences/BrisSEC-2019/BrisSEC19.aspx

The notes in these pages are to help fill out the slides as the slides were speaking points, rather than complete notes.

The usual start-of-a-talk caveat – this is general advice, I’m not a lawyer, you break anything it is your own fault, copyright/etc belongs to the respective owners…

The premise of this talk is that you’ve got a problem to solve; one that involves “the cyberz”.

Typically, you’ve got a significantly smaller allocation of money or budget with which to solve a bigger problem. The ‘ideal world’ doesn’t exist – you can’t simply find and apply every possible ‘fix’ as this is not feasible.

So, how do you define the problem, in information security terms, so that you can apply cybersecurity related fixes?

Providing some background to myself and how I’m approaching this slide deck.

I’m a consultant. (queue “Boo hiss, etc”) but when I am asked onsite I have a few key questions that need to be addressed to define the problem.

I need ‘facts’ to work with. (Technically observations – they may well be perceived facts or even facts, but we’ll lump them together simply as ‘facts’ to avoid lengthy discussion on the topic of ‘observations, findings and recommendations’.)

Regardless of the type of role I do when I go onsite (it could be security-, enterprise- or even data-architect; as well as ‘consultant’) I will always need to collaborate with many different roles inside the organisation, from Business Analysts through ‘Subject Matter Experts’ (SME) as initially I need the view of the organisation, not the views of IT.

Note that there is not singular generic ‘right answer’ – the correct answer for your organisation will depend wholly on its context.

A side benefit of getting out there and talking to many roles inside of the organisation is potentially getting more people interested in information security!

If you ask for help (eg internal or external consultants) and you have already answered these questions you’ll be many steps ahead. Obviously ask for help where and when it is needed… but you may find better ways or areas to implement controls if you understand the organisation better (not just the technology layer).

Beware the ‘pre-canned answer’ – the worst is when a solution is immediately sought, without properly defining the problem. Never ends well, except for the vendors!

Ref: http://www.adrenalan.com/the-problem-is-already-knowing-the-answer/

Going to use Adrenalan’s “three I” because it gives us the 6W (who, what, when, where, why & how) with a cyber slant.

See http://www.adrenalan.com/infoidintent/

Why lets you ask for more money to solve, if needs be. If it’s outside your usual operational scope, (eg new regulation) then you’re better able to articulate the problem (and beg for $)

Why lets you find the correct stakeholders and obtain support from them (when ‘why’ is put back to them as it affects their parts of the organisation)

Further ‘root cause’ reasons:

•        Mandatory… if it’s not mandatory it’s optional, thus a choice to be made. (‘how’ mandatory something mandatory is, is an ownership level discussion, ie Board) Alt: What are the key requirements? Any MUST vs SHOULD? (If $ for it can change in the decision process, it is likely a SHOULD!)

•        Privacy Act, specifically notifiable data breach (NDB) rules having effect, plus GDPR effects (either perceived or real)

•        Remember that Security != Privacy... but you can use a lot of the same controls to maintain both

•        Be able to answer the “mix it with other budget” or inverse

Whatever you find as the root cause ‘why’ is what you need to remember throughout. Write it down. Stick it on your wall, if not too sensitive!

After why the ‘what are you protecting’ is the most important thing for information security people to get their heads around.

This is an area that the organisation needs to be heavily involved in to provide an accurate view of what is important to the org, along with the value of those assets.

Example: you’re not protecting a user’s laptop– you’re protecting the information assets stored on or accessed via that user’s laptop.

Open question for audience – (assume Office365 email sync’d to Outlook running on a device) is the best place to spend money for security controls on the laptop or … where?

This is another way of looking at the ‘what are you protecting’ slide:

What would your competitors most want?

What is valuable to criminals?

Wear your evil hat!

Rule of thumb: don’t spend more to protect assets than they are worth or will cost you if you lose them.

Who needs access to the ‘what’ assets?

Typically: it’s staff, partners, customers… but frequently includes regulators, developers (does that include open sharing to github?).

What’s the full lifecycle (recruitment, onboarding, ‘operations’, leaving, tombstoning, etc) of the ‘who’?

Everything is time bound. An imagined thing delivered in 6 months’ time is just that … imagined – it will do nothing to help you until it actually exists and does its thing. (It may still fail but that’s another story!)

Purposefully not going to use a particular framework here… just the basics – create / operate / destroy.

Can you do it staggered – often referred to as ‘horizons’ or ‘phases’ of a longer project or programme of works. The important part isn’t how it is staggered but that you get the needed security controls in place by the time you need them. (More on security controls later in these slides.)

What are the factors that need to be in place for you to be successful?

Who are the stakeholders that are your keystones for success? (execs, directors/board, regulator, customers… no one is off the stakeholders list)

If putting a stakeholder on the list scares you, then it may just be the correct stakeholder – turn your weaknesses into strengths.

Build trust with your stakeholders must be part of success.

How do you define the ‘right answer’? – speculate: if it ethically enables the org to reach its goals.

Wear your evil hat again – how would you break your organisation?

Run a business red-team exercise (‘desktop’ or paper is a good starting point) – SMEs can often tell you exactly how to break things within your processes.

All DR events I’ve been called into have been process failures, at root cause level, not technology failures. It may have been a technical failure that was the visible ‘bang’ but it’s the process that will have failed to adequately deal with the tech failure.

How’s your recruitment and vetting ‘people’ process? Offboarding? Do you have a ‘walking the staff member out the door’ process that immediately locks that person out of allaccess? (Can you prove it? When did you audit that process with a developer or system admin, just to check it works?)

A few more thoughts on security controls:

Where are the best places to put controls?

-        Peoplecontrols are the most flexible and ‘stick’with the people throughout changes in process and technology. Invest in your people.

-        Processcontrols are changes in how the organisation works and are the most effectivecontrols, overall. (And can enable people empowerment, more than technology controls.)

-        Technologycontrols should generally be as invisible as possible.

When you ‘stick it in the cloud’ it should still conform to your organisational rules… eg build yourself an org-wide-agreed access decision model (this is a whole other talk topic!)

Remember the most expensive part of controls is monitoring them effectively!

Remember we spoke about lifecycle? Infosec has the NIST cybersecurity lifecycle to refer to…

…so here’s a view of some example security controls at the people / process / technology layers, with a ‘matrix view’ across identify / detect / protect / respond / recover.

Since you’re now reading this talk, rather than listening in real time, please review the 6W. Remember – answer ‘why’ and ‘what’ and you can work the rest out from there!

You must contend with the whole lifecycle – create / operate / destroy.

Cultural change will beat tech change.
Process is your org.
People run your org.
Tech supports it.