Whilst a lot of security investment is often focused on Prevention, how do we take the fight to our opponent, the attacker? Short of Hacking Back, we can do a lot of proactive things that make a big impact on security.

A man with a rifle over his shoulder in silhouette at sunruse
The threat hunter prepares for another day

In this article I will touch on some of the activities you can take to be prepared and proactive. These include:

  1. Red Teaming and Purple Teaming

  2. Customisation and contextualisation of security - threat mapping

  3. Secure application development and vulnerability management

  4. Active threat hunting

Let's expand on one of the items above, threat hunting.

What is threat hunting?

Threat Hunting is a form of active defence that seeks to minimise the amount of time that an attacker can spend in your environment before being found. In contrast to traditional preventative controls such as firewalls and antivirus products, Threat Hunting is the process of actively searching for and detecting threats which currently exist within the network and may be actively evading existing security capabilities and solutions.

Who can / should hunt?

Anyone can hunt. Whether hunting submarines, wild animals or truffles, success is usually based on a number of considerations:

  1. Knowing the terrain (i.e. the business and technology environment)

  2. Understanding the target / threat (who / what is the adversary)

  3. Looking for spoor and other signs (e.g. indicators of compromise )

  4. Knowing what to do when you find your adversary (e.g. security incident response & digital forensics)

  5. Understanding when the process is complete and environment is rendered safe once again (who can declare network, data or system integrity)

The question of whether you Should hunt will usually come down to availability of appropriately skilled resources.

Colourful Job ad cards showing Script Writer, Pastry Chef and others
Cybersecurity recruitment may soon turn to alternative skills

What threats should be hunted?

In order to understand what threats should be hunted, the threat hunters must understand credible threats and threat actors, critical business objectives and assets and the existing security and other controls in place.

A man (shirtless) is attacked by a vampire
The valiant threat hunter succumbs to an advanced persistent threat

Even if the organisation is not an obvious target, it may be a critical part of a supply chain for others. So in considering threats TO the organisation, consideration should also be given to threats FROM the organisation.

It should be noted that threats can, and do evolve. One basic malware infection can become a network compromise, a ransom attack and ultimately a data breach.

As compromises often remain undetected for many months, consideration should also be given to the frequency of hunting activities.

How does threat hunting work?

One of my past articles outlines some of the processes involved. A high level overview of the process is below.

Threat Hunting Process Overview
Threat Hunting Process

Do I need a dedicated threat hunting capability?

The question as to whether a dedicated threat hunting capability should be in place usually comes down to capability, capacity and cost.

Aerial photo of armed soldiers preparing to deploy
The threat hunters prepare for a nation state threat actor

Maintaining the skills and tools to perform threat hunting effectively without impacting security operations typically requires a very large security team. With overwhelmingly strong industry competition, attracting and retaining security talent has become increasingly challenging.

Having a wide variety of options to choose from, security practitioners are being constantly tempted to take on more lucrative and sexier roles.

This represents both a risk and an opportunity. For organisations with mature security capability, backfill and training of less experienced talent, and up-skilling internal key resources can provide a more interesting and dynamic role for the experienced security expert.

This does however come at a cost and many organisations still either:

  1. do not understand (or see the immediate value) in threat hunting

  2. do not understand (or cannot adequately quantify) the risks that threat hunting helps to mitigate

  3. have other, more immediate operational security imperatives and are still operating in a reactive mode

  4. leverage external services to obtain threat hunting on a periodic basis

If you would like to discuss how we can assist you to hunt threats within your environment get in touch.

Author: Clinton Smith

75 views0 comments

Accidents happen, although accidents in managing security can have some serious and unexpected consequences.

This article discusses what should be basic measures for most organisations, yet still some lag way behind (aka the slow moving gazelles - a much loved staple of the carnivores).

A person snorkels next to a large (menacing looking) great white shark
The security manager taking a casual dip

During a discussion some time ago about SCUBA diving, I enquired:

why do divers carry knives? - Is it to defend against an attack by something scary?

The somewhat unsettling (joke) answer was:

no, it is to cut or disable other divers

(inferring that this would result in someone else being attacked by something scary)

This illustrates common principles (and beliefs) of:

  1. Safety in numbers (perhaps I can use my fellow divers as human shields)

  2. Survival of the fittest (perhaps I can swim faster than my fellow divers)

  3. Being prepared to acknowledge and address the risks of the environment (perhaps I want to go diving in a swimming pool instead)

(The real [and far more politically correct] answer was to cut free from entanglements such as ropes / weed etc)

So what happens when all positions on the food chain are at risk, and the predators are automated (e.g. Terminator)?

A few things are likely to occur:

  1. If an attacker is motivated and capable of exploiting a weakness that you have, and they have opportunity to do so, chances are they will.

  2. If you are uninformed, unaware or rely on belief, but make no attempt to ensure your assets are protected - chances are you will become a target.

  3. If you have a large, complex and vulnerable attack surface (e.g. your network, your data, your people, your supply chain, your systems) and are less vigilant than an attacker - chances are you will be attacked.

In much the same way as the injured moving tuna in a school of sharks can be open to becoming lunch, vulnerable systems on the Public Internet are exposed to attack.

The critical factors involved in this are (as above) that there is a threat, a vulnerability and a foreseeable (and probable) consequence .

A seated view from a tatami mat into a tranquil Japanese garden
The view from the well prepared security operation centre

So what can we do to avoid security mishaps (credit to Sun Tzu)?

  • Know yourself - establish security situational awareness, and be aware of your assets

  • Know the enemy - understand the realistic threats and attacks you may be exposed to

  • In time of peace, prepare for war (response) - don't rely on prevention alone

In addition, (to those of us without large armies and the backing of a nation state)

  • Prioritise - address the most important concerns on the basis of risk

  • Baseline - understand what normal looks like, so abnormal can be detected

Expanding on these concepts, effective management of security is typically based on some simple principles:

  1. Understand your critical business processes (and objectives)

  2. Understand the systems and information that supports these critical business processes

  3. Understand relevant threats and risks to these systems and information

  4. Understand your internal and external obligations (e.g. compliance)

  5. Empower business stakeholders to make informed risk decisions around security

  6. Adopt security strategies based on the cyber kill chain and your risk appetite

  7. Maintain a flexible and adaptive security incident response plan that has playbooks for key / common incidents.

In order to implement security controls where they are needed most, you need to know what asset(s) you are protecting, the threats and risks you consider credible, where these assets are, and what other controls you have in place.

A lady with a bike holding a camera in one hand
Not all risk assessments are boring.

In the physical world, these are reasonably simple things. As an example, one of your family may ride (the process) a bicycle (the asset) to work:

  • you are concerned about safety of the rider - so you obtain a helmet and a light.

  • you are concerned about theft of the bike - so you obtain a chain and padlock.

  • you are concerned with equipment failure - so you obtain a spare tube and pump.

Whilst your loved one could break the road rules (external compliance) - you educate, inform and empower her, trusting that she will make good and informed decisions (e.g. to wear a helmet, and obey traffic signals).

Key takeaways are to seek to fully understand the interactions between your attackers, your defences and your assets (i.e. the cyber kill chain), establish controls based on your risk appetite, prioritise your controls and have a flexible incident response process.

If you would like to better understand your security exposures and gaps or confirm whether your defences are resilient to attack - contact us

Author: Clinton Smith

16 views0 comments

Consider this a cheat sheet of cyber security (and other) things to consider when managing a project.

3 kitens exploring
Herding cats can be a full-time job

If we consider some of the important dimensions (and common success factors) of a project such as Scope, Sponsorship, Leadership, Capacity, Capability and Competence, Processes, Technology, Tasks, Timelines, Budgets, Deliverables, Scheduling & Sequencing, Dependencies, Constraints, Risks, Compliance obligations and Communication, typically these are established (and vigorously defended) by a savvy project manager.

As projects often have many internal & external dependencies, one challenge for modern technology projects (or business projects that leverage, depend on, or impact technology) is to maintain visibility and awareness of things that can influence these dimensions (i.e. risks).

A young boy with binoculars crouching in grass looking back
The young project manager watches his dependencies

I recall a conversation with a veteran project / program sponsor many years ago, who (initially averse to the language of risk) came to understand that most of her career had involved risk management of one form or another.

A white page of boxes with a hand (and ballpoint pen) ticking them
The mythical project checklist which details everything

So how can a project manager integrate cybersecurity risk management into their projects?

Here are a few tips which project managers have found helpful:

  1. Request / obtain all relevant risks, audit items, requirements (policies, standards, procedures & compliance obligations)

  2. Request / obtain all relevant business, technology, risk management strategies

  3. Consider the items above as inbound requirements to a project, capture, confirm and manage these as with any other requirement.

  4. Consider the delivery and execution risk(s) associated with what the project intends to do (i.e. activities)

  5. Consider the risk(s) that are being addressed (controlled or improved) by the project (i.e. usually a project will help to reduce risk, having these documented provides a balanced benefit view and helps to keep stakeholders focused) - e.g. if the project is to introduce new ways of working and there are technology changes included (e.g. changing desktop operating systems) - invariably, these will bring reduced risks and improved security, as more modern, supportable platforms can reduce risk.

  6. As projects can sometimes be the first time (in recent history within an organisation) that anyone has considered a pre-existing risk - take care to call out any pre-existing risks to ensure that stakeholders know this, and then ask the question, "What is changing, and how does this affect the pre-existing risk". In some cases the change may be a project initiated activity, but it could equally be the degradation of an existing control that is no longer effective or an increase in the consequence or likelihood of a threat.

Based on knowledge of the items above, resolution, escalation and approval paths will typically be clearer. Without this information it is often hard to know whether you are dealing with a well-known, pre-existing and accepted risk (that is usually owned by someone operationally) or something new or novel (and could be owned by the project or its sponsor).

What does a project security engagement model look like? Here are a few:

A grey jigsaw with a final blue piece being inserted
Cybersecurity is known to be associated with flouro blue

Dedicated resourcing - Specialist (architecture and design resources) security resourcing is established early in the project. This works reasonably well for large, complex and well funded projects. The downsides can be that skills may need to be generic (Jack of all Security Trades), and that this has a cost implication. The upsides are that (where properly integrated) this should avoid surprises and can provide a more streamlined simple model.

  • Key considerations: To be effective, security should always be driven from Risk, Compliance or Utility so managing security resources should always bring discussion back to what is being addressed and why?

  • Note also: General security practitioners may face a steep learning curve with new technology it is therefore important to allocate adequate time to research this or obtain external skills where required.

Periodic checkpoints - Specialist (assurance and consulting resources) are engaged at logical milestones in the project to provide input to and feedback on project activities and artefacts. This works reasonably well for maintenance and platform projects where there is a lot of documentation produced. It allows for greater precision in allocating security skills and allows for overall process efficiency to be considered.

  • Key Considerations: As engagement is centred on artefacts, the quality and completeness of these is important. In addition, the security practitioner may need to consult with resources that are now busy on other activities.

  • Risk of rework: as the project can progress too far down a particular path it may involve re-work. Also, project deadlines and limited notice can place additional pressure on external resources (e.g. compressing their timelines). The upside is that the engagement is highly targeted, and where there is a risk of slippage or other dependencies, it can be easier to integrate security and other feedback (e.g. architecture)

  • Moderation: Specialist security practitioners can have deeply held (almost religious) views on certain things, and these may need to be moderated and managed with a broader audience where required.

  • Anxiety Management: Using an early 'heads up' informal security briefing throughout the project can help keep the two camps aligned and reduce surprises in both directions.

Deliverable assessment and feedback - Formal project gates with requirements management and structured assessment and feedback can work very well where this is understood and part of the furniture. This works well in mature environments that would better wear a cost or time over-run than a security / compliance breach.

  • Key considerations: As with the previous approach, this is very focused on tangible artefacts, requires a very well defined governance structure and formalised accountabilities. Risk and Compliance must also be mature, well understood and agreed by the participants to avoid a 'build your own governance approach' during an inflight project.

  • Approval by committee: The drawbacks to this type of engagement are that documents and artefacts can go through multiple approval rounds and can (if not properly managed) miss / exclude / over-emphasise requirements or lead to a decision impasse that needs to be escalated. (matrix management). The upside of such environments are that there is usually less conflict as stockholdings and governance are better managed through the bureaucratic processes.

  • Governance: This approach can involve the escalation to risk and control owners, and as such is better suited to environments which have an effective GRC structure.

Efficiency, cost containment and execution

The last thing a project wants and needs is an expensive security person sitting & waiting.

A mans hand wearing a suit places a gold coin into a small jar (held by someone else)
The project manager paying contract resources

So how can we tackle this:

1) Understand the project lifecycle, milestones, and logical engagement points for security e.g. if you do not understand your threats, risks, controls, obligations and governance required get some focused upfront (security scoping) assistance to determine what is needed.

2) Leverage well-known (defensible) sources of guidance i.e. Internal Policies and Standards can help to quickly solidify organisational security expectations.

3) Conduct periodic, logical check-ins with security stakeholders based on project phases / milestones. We would usually suggest things such as the following:

  • Concept & initiation - identify any big ticket considerations / mega risks / mega costs as well as help to identify likely issues and incidents and pre-empt a response. If a project introduces more risk than benefit - here is the time to know.

  • Definition and planning - define any critical goals / activities that relate to security or risk management. Good security advice upfront will reduce cost, delays and re-work. Here also, a good security person will be proactive and make recommendations on what to do if things go wrong (e.g. having a data breach playbook to support a large and complex data migration).

  • Launch or execution - upfront planning for security and risk will take the guesswork out of what your security personnel will be doing, development, delivery, verification etc throughout execution.

  • Performance and control - just as with many other disciplines, data and timely information are vital. Key risk and key control indicators can provide early warning of an impending problem. Integrating security as an aspect of quality, and conducting testing to confirm resilience is a practical example and provides confidence.

  • Project close - More than just an opportunity for team lunch / drinks, it is important to circle back and confirm our closing risk position and outcomes. This usually involves discussion around the acceptance of some risks or new control custodianship.

A small village sits atop a mountain in a forrested area
The secret mountain lair of the reclusive security managers who were hunted to near extinction by early project managers

Common Gotchas: Here are a few security things that can sometimes get missed in a project:

  • Understanding information repositories and flows. This can help to identify weaknesses in processes or protection. e.g. "We simply extract the data onto a thumb drive and send it by post to our developer."

  • Having a plan for managing a security incident during a project. (This could be as simple as shut the system down, or involve a full step-by-step plan in cases where the system and its data are integrated across other platforms and possibly 3rd parties, e.g. using a 3rd party credit check API hosted by a partner).

  • Documenting the threats that will (and won't) be addressed in the project. (e.g. DDoS is usually an exclusion).

  • Consideration of what the changes will mean on existing security controls (e.g. implementing encrypted traffic will remove the ability to inspect it for malicious content).

  • Integration of the changes into security operations (and any training / uplift etc that may be required [see previous comment re: playbooks])

  • Integrating security testing (when, where and how) so that security defects can be considered in existing changes / releases / drops or remediation.

  • Capturing any specific security and risk objectives of the sponsor. (e.g. "The integrity of the website content must be protected at all times")

  • Consideration of any uplift in cost and effort for security management / licensing / storage etc. (e.g. uplifting this platform will produce another 500Gb of logs per day that need to be stored, processed and analysed)

  • Risk integration (management, assessment of changes, risk acceptance) & risk governance processes.

  • Security documentation (new or amended) such as a platform security standard or network security map.

Final thoughts: Project management is complex. If you have made it to the end of this article, I hope this has provided just a few tips to help better manage security in your projects.

If you would like to discuss how we can assist you to manage security and risk in your projects get in touch.

Author: Clinton Smith

343 views0 comments