• Clinton Smith

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).

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 .

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.

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

  • Clinton Smith

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

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).

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.

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:

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.

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.

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

  • Clinton Smith

Updated: Aug 29, 2019

Fires are hard to contain and require specialist assistance

So your organisation has done everything right to effectively manage security. You have the best technology, a crack team of security specialists, well-tested applications and infrastructure, a cyber-aware workforce and rigorous processes for detection and response.

Having reached this enlightened place of happiness and well-being - is it now time for quiet contemplation or celebration of a job well done?

The information security manager reflects on her mastery of risk and compliance

Due to the unrelenting nature of the threats, It is little surprise that many security teams suffer the corporate equivalent of PTSD. So what should a mature organisation do to help iron out the kinks and improve the efficiency of its incident response processes?

In the same way that we test a building evacuation, a DR failover or a backup we want to 'drill' these events so that when / if we have to perform them in real circumstances we have a working, well-tuned process and everything in place that we need.

Just as in the real world - we would not want to test a building's resilience to a fire by setting it alight and admiring our expert sprinkler and alarm setup. Instead, we 'simulate' the alarm safely and under supervision, and get people ready to evacuate.

So how do we do this for a cyber attack? Well the answer is reasonably straightforward - we simulate a cyber attack. Under controlled conditions (rules of engagement) - we conduct activities that the organisation should ideally detect and respond to.

Red teams simulate a realistic attacker

So what things do clients generally learn from a red team event?

  1. Security is not a technology or product that can be simply purchased.

  2. An organisation's largest attack surface (and most valuable security control) is its workforce.

  3. Security incident response is an orchestration of People, Process and Technology and relies on effective leadership and communication.

  4. An organisation with a well-resourced and trained security incident response team, supported by realistic playbooks is worth its weight in [Gold | Bitcoin | etc].

As Red Team testing is an advanced assurance activity, it should ideally be conducted only by organisations that consider that their security incident response is reasonably mature.

How do I know if my organisation is ready to perform red team testing? You would ideally:

  • have an experienced cybersecurity leader for your security incident response team

  • have a program of security awareness to educate all personnel about the risks

  • have an approved, well-documented, formalised security incident response process

  • have incident-specific playbooks, supported by a well-resourced dedicated/virtual team

  • have sufficient logging and monitoring for your important networks and assets

If you would like to discuss how we can assist you to test your cyber resilience get in touch.

Author: Clinton Smith


Sales:          sales@esecure.com.au
Careers:      jobs@esecure.com.au

LinkedIn Logo
Facebook Logo
Twitter Logo
GlobalMark Seal
CREST Australia and New Zealand Logo

e-Secure Pty. Ltd.

ABN 48 086 248 419

Copyright 2020 e-Secure Pty. Ltd. All rights reserved