IT – CTO / CIO

Many could argue that the origination of cyber security teams grew out of technology departments, particularly IT. Those early days of the industry often saw cyber grow out of ‘Network Security’, generally those resources configuring and operating firewalls. Or even resources central to the management of logical access.

In many cases your cyber teams being central to technology makes sense, the teams are close to tech strategy and can potentially make the most impact close to those resources integral to technology change. CISO reporting to CTO or CIO makes sense in many ways as well, the voice for technology change with your executives, the CTO / CIO can drive positive change for cyber from a top-down approach. Arguably the likelihood of your CTO / CIO understanding the subject is high as well, especially within the realms of technology domains with cyber.

On the other hand, there are potential negatives surrounding situating your cyber teams within your Technology departments and reporting to CTO / CIO. By far the biggest issue could be the potential of a conflict of interest, especially where change for the improvement of cyber may conflict with general technology change. Examples could be the introduction of stricter authentication controls, such as PAM (Privileged Access Management). From a user perspective this could be seen as ‘slowing’ them down and your reporting lines up to the CTO / CIO could hear that negative feedback. What choice will the CTO / CIO make – improvement of cyber Security or ensure zero impact to throughput with technology resources?

Finance – CFO

Another common approach for reporting of cyber teams is through the CFO. Taking an approach of segregating the cyber teams from technology, this approach ensures little to no conflict of interest as discussed in the previous example.

There are positives to this approach as well. Not everything within cyber is technology focused and a large amount sits within the GRC (Governance, Risk and Compliance) domains. There are many opportunities for synergies with your central Risk and Compliance teams, that often sit within the CFO reporting lines. Your CFO will often have a good understanding of the core GRC concepts and generally can easily apply this to the concept of cyber-Security, providing a valuable resource to lead from an executive perspective on positive cyber change.

On the flip side of this, a negative to this approach means you are not as central to technology change as the previous example of reporting to the CTO / CIO. This could mean you miss out of the opportunity for ease of integration within your core technology strategy and operations. Out of sight, out of mind could mean your direct involvement may be lost within technology teams and thus, lose momentum towards positive cyber change.

CEO – CISO

A less common approach, which is becoming more popular, is the CISO having a seat at the executive table with direct reporting to the CEO and or Board. Supporting the seriousness of the subject of cyber at the most senior level in the business, this ensures that cyber is considered direct within business strategy from the top down.

The CISO sitting alongside your executives makes a clear sign internally and externally of the seriousness your business takes cyber security. Independently reporting to CEO, Board or both, ensuring no conflicts of interest. This approach is the clearest way to ensure cyber is considered within business objectives and strategy from the ground up and discussed at the most senior levels.

However similar to previous examples, this option can be the most isolated. Without the direct reporting to either the CFO, CTO or CIO – will your cyber teams be able to ensure positive cyber change is driven across the business? Will the benefit of direct reporting to the CEO, outweigh the importance of direct integration with your technology or GRC teams?

Does it really matter?

Ultimately there is no one size fits all here, your choice will entirely be dependent on the make up of your own business taking into consideration your business objectives and maturity. A security programme can be successfully driven by a CISO reporting into a CFO, CTO, CIO or a CEO – it all comes down to the capability of the CISO coupled with the seriousness and maturity of the role accountable. Conflicts of interest can arise in any one of these options but can also be navigated through successfully with someone of the right mind to work through.

So does it really matter who the CISO reports into? I’d argue no, provided that the CISO has the relevant seniority and ability to drive the security agenda. There are obviously certain ways to set your store up for success, such as options for direct board reporting – but it is what the CISO makes of it.

Conclusion

In todays organisations where everything evolves around the Digital World, is it not time for the CISO to be sat at the top table alongside other C-Suite members? Or do you think the CISO should report into someone different? Let us know in the comments!

Response to this ongoing conflict has seen response to the risk of cyber attack be heightened, with directions from various agencies recommending increasing your cyber defence posture. A regularly recommended set of tools are provided for free by the National Cyber Security Centre, including the Early Warning Service. In the following blog piece CIISF member Ewan Traynor provides information on this service and insight as to why you should be using this, if you’re not already using a similar toolset.

What is NCSC’s Early Warning Service?

The NCSC’s Early Warning Service is a free and open product, for organisations in the UK or Crown Dependencies, that enables you to be informed of potential cyber-attacks on your network as early as possible. This service does not conduct any active scanning itself, instead it utilises many cyber threat intelligence feeds and correlates this data to find any of the domain names/IP address that you have supplied to be monitored.

How do you sign up for it?

As long as you are an organisation in the UK or Crown Dependencies you are eligible to be signed up for free, including Crown Dependencies. To sign up visit the following link “NCSC Registration”. Once you have created your NCSC account, you will be able to sign up for the early warning service. You will then just need the name of your organisation, public IP’s/domain names, name, and email address you would like the alerts to go to.

How do you use it?

Once you have supplied the early warning service with all the information that is needed, you will start to receive alerts daily to the email address you provided and weekly vulnerability alerts. Both come in the same format but do have differences, which we will discuss later.

How does it work?

The early warning service is a tool that uses cyber threat intelligence feeds (open source, closed source, and several privileged feeds) to correlate data. It then applies filters applicable to the business on the data that is being ingested, searching for anything to do with the IP addresses and domain names you have given it to monitor. It then bundles up these alerts up into a csv file and they are sent to an email address you have chosen.

Why use it?

It is a free service, that enables organisations to be alerted on the presence of malware/vulnerabilities/intrusions affecting your network. This tool can be used to enhance your awareness of assets, incidents and vulnerabilities that may not have been picked up. The service is something that can be incorporated into your already existing security tool kit to provide further enrichment to your security events and incidents.

It is also common for a potential attacker to utilise similar scanning methods on the public internet to look for ‘low hanging fruit’, you can utilise the functionality of this service to check whether you’re not exposing your environment and any associated weaknesses to the internet and where identified, mitigated said weaknesses.

Weekly Vulnerability Alerts

The following image is the report that contains alerts related to vulnerabilities and open ports. It can be used as a great way to observe your environment from an attacker’s point of view, enabling you to better understand weak spots in your attack surface.

In the above screenshot some of the information has been redacted to ensure safety of the particular assets. In the weekly report you can see we have numerous types of vulnerabilities, anything from an open port to a weakness that can be used to gain remote access on the host. Using this information, it makes it relatively easy to then locate the host and start to remediate the vulnerability.

Daily Threat Alert

The daily report contains alerts for network abuse and incident notifications. This is where you can start to spot compromises that may have not already been picked up within your organisation.

In the above screenshot we have our daily threat alert csv we have received. The first two alerts here are for two different hosts that have been compromised and now are part of a botnet. The last alert is letting us know that a host has been engaged in port scanning or web scraping activities. Using this information, we can then locate the host and begin our analysis to remediating the infection.

For more information, including case studies we recommend visiting: Early Warning - NCSC.GOV.UK

- Ewan Traynor

Now, I’ve said this before in articles I’ve written, but I’ve always been quite impressed with the Government’s record on consulting the populace when bringing in new laws, policies or standards. It’s refreshing that people with knowledge and valid opinions are asked to share what they think and know, and since the first consultation happened back at the beginning of 2022, it’s clear that the views given have been listened to.

Anyhow, I must stop bigging up the government and get back to the point. If you’re thinking that the new Cyber law is basically a copy-and-paste of the Data Protection laws with a few words changed, you’d be miles from the truth. The latter is liberally scattered with numbers like £5million and £10million for administrative fines handed to transgressors; the maximum fine for not doing as you ought in the new Cyber law is £10,000. Not quite peanuts, but not far from it.

And the point is that the primary purposes of the law are: (a) to establish the Jersey Cyber Security Centre (JCSC) as a thing in its own right, at arm’s length from the Government and with the powers it needs to help Jersey retain a good level of cyber security; and (b) to encourage organisations to report cyber breaches so JCSC has sight of what’s going on around the island, can see common threads to attacks that the island is suffering, and can do whatever’s feasible to try to reduce the risk or at least let organisations know what’s happening so they can take action themselves.

If all the law achieves is to get companies in Jersey to tell the JFSC about the attacks they’ve suffered, then it’s not a bad thing. I’m a massive believer in sharing experiences about cyber attacks they’ve suffered (either successful or otherwise) but it’s entirely understandable that companies don’t want to for fear of reputation damage or even regulatory or legal sanctions. It feels that openness is becoming more and more the norm (in fact I’ll be at a conference later this year run by an organisation whose raison d’être is to collate and share information on cyber threats in the global financial services industry) but there’s still a long way to go before we achieve proper information sharing in the Channel Islands.

Could the law be stronger? Should it, to come back from a concept mentioned earlier, be a cyber version of the Data Protection law? I’ve banged on about State of New York’s cyber law before – whose powers and requirements bear more than a passing resemblance to GDPR – which is impressive and scary in approximately equal measures. Should we be obliged by law to have a Chief Information Security Officer in certain circumstances? Should annual penetration tests on our internet-facing stuff be mandated? Should it be compulsory to encrypt data in transit and at rest? It probably should, to be fair, but as always the expression “it depends” is the starting point.

And “it depends” for two reasons. The first is size and nature of business: if you’re a bank then it would be pretty bonkers not to have a CISO, but what if you’re a small insurance brokerage? And the second reason is: even without a law, many of the organisations to which the law applies (“Operators of Essential Services”, or OESs as they’re called) already have to do a lot of cyber stuff in order to comply with the various other laws of the land, their internal policies, and the rules of their regulators. In my day-job as CISO of an arm of a global bank I have a barrage of Group-defined and regulator-inflicted requirements to abide by with regard to cyber risk, so I don’t really need them all repeated in a local law. But to add a thin layer of law – which empowers JCSC and encourages/mandates us to give them the information and intelligence they need in order to understand and improve Jersey’s level of cyber security – doesn’t sound like a bad thing.

Should the law become stricter over time? Yes, probably: cyber risk is only going one way and that’s up, and it’s highly likely that at some point in the future it’ll make sense to add stuff that nobody’s thought of (or which helps deal with threats to/from future technologies that don’t exist right now). Is it perfect in its current form? No, and the team running the consultation acknowledge this (hence the consultation!). But on balance it’s a good idea, and I encourage anyone with an interest to dip into the consultation and take the opportunity to say your bit.

--Dave Cartwright

TI (“Threat intelligence”) is a daunting subject within cyber security, so much so that in fear of not getting it right, we often avoid attempts at implementing it within our operations. The allure of a shiny TIP (“threat intelligence platform”) to solve of your problems is enticing, but without the basics implemented within operations, you will often end up with another tool providing little to no value.

The truth is TI is complicated and that cannot be avoided. However, it is entirely possible to start your journey towards implementing some form of TI process within your operations, then continually improving as the operations matures.

Before we talk steps to introduce such processes, some key concepts are worth noting:

What is threat intelligence in the context of cyber security?

TI is not a concept that is easily defined, nor is there one agreed definition within the sector. This is largely because as a concept it includes a wide-ranging number of different approaches dependent on your particular use case.

In its most basic form TI is the identification of information related to threats or the potential of threats in the context of your business and operations. In our context we are considering TI from a cyber security perspective, sometimes referred to as CTI (“Cyber Threat Intelligence”)

Practically this means that within your operations you need:

• The ability to identify threat information, often utilising such things referred to as threat feeds.

• A process to apply business context to threat information, such as knowledge of your assets and their applicability to a particular threat.

• A process to assess threat data as to the risk related to your business, including potential scenarios whereby the threat could become realised.

• The ability to react to your risk assessment and apply some form of mitigation or potential tolerance to the threat identified.

Threat intelligence as a subject can go into much more depth and I would recommend the NCSC guidance on building a Security Operations Centre section on TI as a starter to researching more: Building a Security Operations Centre (SOC) - NCSC.GOV.UK.

Types of Threat Intelligence

There are many different types of TI available for our SecOps teams to use. Any form of information that you find useful to informing the potential of threat towards your business can be considered a TI.

Consensus is that TI is broken down into four distinct categories:

• Strategic – High level and non-technical, general focused towards your senior stakeholders and encompasses summaries of the three other types of TI.

• Tactical – Flexible in its approach, this type of TI is often related to your daily SecOps ability to respond to TI to prevent the potential for compromise.

• Technical – Generally the detailed technical information received from threat feeds such as IOCs (“Indicators of Compromise”) and to be used either in response to an incident or to prevent future incidents.

• Operational – Sitting outside of the technical aspect, this covers the wider human elements of TI such as OSINT (“Open-Source Intelligence”) such as the monitoring of Dark Web communications for the indicators of attack.

Each type of TI can be summarised in much more depth and there are many resources available online to research further.

Introducing TI to your Security Operation

Introducing TI to your SecOps can begin with the implementation of a formal process which should include the necessary steps for the lifecycle of TI, from identification to potential feedback. The key steps for any TI process should consider:

1. Identification / Collection – The first step is to identify your chosen threat feeds (examples listed later in this article) and start collecting your data. In the early stages of your TI journey, collection of data can be managed utilising tools readily available, such as your ticket management software or even the dreaded excel. As you mature, utilising more robust options such as MISP (“Malware Information Sharing Platform”) should be considered.

2. Handling / Processing – Once your data has been identified and collected, a process to ensure it is in a format that is usable will need to be performed. This could just be as simple as taking the information gathered and ensuring your core elements of data required, including such things as the source of the information, CVE scoring if applicable and even any IOCs available and documenting them in a consistent format to be assessed.

3. Analysis / Assessment – In this step you will take the information you have gathered and documented, then analyse it for applicability to your business and context. This often can include attribution of the existence of the threat within your business, alongside a formal risk assessment. It is important to ensure your analysis and assessments are documented and evidence-based where possible. Being able to evidence good decision making within the context of TI will be important for future continual improvement and compliance efforts.

4. Notification / assignment – Once your analysis and assessment are complete and where a threat has been attributed to being applicable to your business, it will need to be assigned and or notified to those responsible to action. This step can include the formal logging of a ticket, with your identified information to an asset owner for action. It could also include notification to a particular operational team of specific indicators to watch out for, to ensure a particular threat is not realised, or the ability to identify if it is. It is important to note that not all threats can be avoided, however the more information you have, the better you can respond.

5. Feedback loop / continual improvement – Like most processes, TI is not exempt from the need for continual improvement and the feedback loop of the usefulness of TI, either the information itself or the process is incredibly valuable. This feedback loop should be used to ensure your process is always improving and should inform the types of threat feeds you may eventually choose as you move to a more mature TI operation.

The important take away is to ensure you have a process documented and formalise the steps, including documenting your decision making.

Threat Feeds

The one blocker that often stops many SecOps teams from introducing TI processes is the availability of threat feeds. There are many TIP and other paid for threat feeds available on the market, but equally there are many more free and open source options available as well. Each may come with a level of maturity to implement, however some initial types of threat feeds that can be used very easily are:

• OSINT (“Open-Source Intelligence”) / Research – Open-source intelligence can itself come in many forms, but in essence is often defined as the option to gather freely available information from publicly available sources. For examples a threat actor researching your CEO via LinkedIn will be considered OSINT. Likewise, your SecOps teams regularly reviewing publicly available information to identify threats, such as reviewing bleeping computer (BleepingComputer | Cybersecurity, Technology News and Support) daily can also be considered OSINT.

• Vendor led – One key element of threat feed that is often not considered as part of your operation is your vendors themselves. Having a central process to monitor your vendors for notification of threats and vulnerabilities is very important. Although sometimes flawed in respect to the time to notify of vulnerabilities and threats, in the early days of implementing a TI process within your SecOps, vendors should not be ignored.

• NCSC CISP (About CISP - NCSC.GOV.UK) – CISP is a platform for security professionals to share threat intelligence and collaborate. Having gone through a recent refresh, it is a valuable tool for joining specific groups either related to operational domains and or even industries to collaborate with likeminded professionals. It is often useful to integrate reviewing CISP into regular checks for the identification of new threats.

• Information Sharing Groups – An often-overlooked element of threat feed is joining information sharing groups. These groups can often exist specific to industry, facilitated by vendors or even by groups such as the NCSC or locally JCSC. They are generally covered by formal terms of reference whereby the sharing of data is controlled by a traffic light system to ensure members are comfortable when sharing information, it will be handled well by others. Membership can be very valuable and often provides a personal touch with respect to understanding how others have responded to threats, providing an initial jump ahead in learning.

There are many more threat feeds available such as OSINT MISP feeds and open-source toolsets available. An important step when initiating your TI process is running through a requirement gathering process at the beginning and researching your threat feeds and choosing which is applicable to your business. Then as you mature you can expand your operation to include those which may need a bit more knowledge to introduce, such as MISP.

Summary

TI can seem daunting but can be achievable if you approach it as a journey. Make sure your requirements for threat feeds are achievable, implement a process and continually improve.

There’s lots of documentation out there to help with cyber security incident response, but sometimes it’s not what you do that matters, but how – and how ready you are to do it. At this month’s CIISF seminar on incident management, both Dave Cartwright and I spoke about the aspects of incident management that you can’t get from a policy, playbook, process or checklist.

If you’ve not personally dealt with a major crisis, one of the hardest things to understand is how a crisis feels. And whether you have had your own crisis to deal with or not, one of the hardest things to appreciate is how much control you do have over that experience and therefore the outcomes.

This week, a local organisation that that had recently suffered a ransomware attack came to talk to us. It was hard to hear, because the story they told was one of personal trauma and challenge.

When their business was attacked, the first thing they saw was unusual systems behaviour. They called in their IT team, thinking this would be a routine issue and easily resolved. It was the mention of the word ‘ransomware’ that rang alarm bells.

Ransomware was confirmed and they called their insurance company who were able to connect them with a specialist incident response and forensics provider.

However, the experience of waiting for the experts and wondering if you are doing the everything you should or not, all whilst watching the business or organisation you have build collapsing around you, is not a fun one.

And two things would have helped.

One would be having someone by their side for friendly advice, support and encouragement, and to sense-check the actions being take and provide another point of view if needed. Just having an expert to talk to – someone local, who can pop round or whom you know – can provide a lot of confidence and peace of mind. And with that support comes the mental space and clarity to make good decisions.

Secondly, everything is easier when you have been there before. In that way first cyber security incidents are the same as a first step, first tax return, first job interview or a first kiss - indeed anything else often approached with a degree of rational trepidation. Some things you just can’t practice for, but cyber incidents you can. Though awareness month we ran a series of cyber incident response exercises for everyone to participate in. We ran a further exercise this week at NatWest’s Library Place branch attended by 10 representatives of different local businesses. The great thing about these exercises is the opportunity to work through a real life scenario with others in a trusted and judgement-free environment. It’s also an opportunity to feel some of the tension that comes with a real life incident, but without the personal or business implications.

This is type of support that Jersey Cyber Security Centre is well placed to offer. Local charities can also call upon cyber security help from the Jersey Charitable Skills Pool. We will run more events and if you’d like a heads-up when we do, make sure you are following both JCSC and the CIISF on social media.

Finally, one of the things that helped the organisation in this case study was having cyber insurance. Insurance is not a panacea and you still need to have effective controls. A great way to start with both is to do a Cyber Essentials or Cyber Essentials Plus certification, which is the minimum baseline recommended by JCSC and a requirement for supplying the UK and Jersey Governments. It also provides £50,000 of cyber insurance cover for free, which would be enough to initiate a response and potentially cover the costs of a smaller incident. Just as importantly however, insurers can help you manage the process and connect you to the right experts at the right time.

If you’ve yet to do CyberEssentials, it’s not too late. You can ask your preferred IT supplier or go direct to one of the four local specialist providers now accredited to certify against CyberEssentials. These are Clarity, Resolution IT, Prosperity 24/7 and CyberTec Security.

In what feels like the blink of an eye, another year has passed, full of both breaches and hopefully progress in the world of cyber security. New Year’s is both a time to refresh and plan for the year ahead, but also to reflect upon the previous year, both positive and negative. Committee members here at the Channel Islands Information Security Forum looked back at 2023 and our top lessons learned:

The value of conferences and networking.

Cyber conferences are as useful as you make them. We all go to conferences and trade shows from time to time, and often get minimal value from them. But if you plan properly whom you're going to visit and what presentations you're going to attend, and you'll be amazed at the value you get. And don't think for a moment that you have to be some mega industry guru to be asked to present: if you have a good idea for a presentation, or you think you have the knowledge to be part of a panel discussion, offer your services and you may well be asked to join in. And it's tremendous fun doing so.

Supply chain security is not going away any time soon.

2023 has seen an increasing focus for many businesses upon supply chain security. This scrutiny is generally driven by regulatory, legal and or compliance requirements, but we’ve also seen several breaches and incidents introduced through supply chains that directly raises the importance of managing your supplier chain correctly. The impact of this scrutiny can be seen on a regular basis for those businesses in the middle of supply chains, with increasing questionnaire, risk assessments and audits becoming more and more common. Questions are more regularly being raised as to the sustainability of such scrutiny, which seems to be creating an industry. There are many potential solutions, but one thing is sure – this scrutiny is not going away in 2024 and is likely to increase.

Cyber security is a team sport.

The successful implementation of cyber security strategy often hinges on correct culture within a business. Cyber security leaders are not the cure to cyber security woes alone, having an isolated security team will generally lead to problems with positive cyber security culture. To be successful our cyber security leaders must work with the wider business in a positive manner, ensuring risk is owned appropriately and subsequent decisions related to cyber security are more appropriately considered and not just seen as an issue outside of responsibility of the risk owner. Work with your wider business, including technical teams, include them in your journey to improve cyber security posture, from strategic planning all the way to incident response.

--

With that, all of the committee members here at the Channel Islands Information Security Forum wish you all a Happy New Year and look forward to hosting more events through 2024!

27 November this year saw the publication of “Guidelines for secure AI [Artificial Intelligence] system development”, a collaboration between the UK’s National Cyber Security Centre (NCSC), the US Cybersecurity and Infrastructure Security Agency (CISA) and over 20 other national cyber agencies across the globe.

In many ways, the guidelines tell us a lot of stuff we already knew. Concepts like “acquire and maintain well-secured and well-documented hardware and software components”, “manage your technical debt”, “apply a holistic approach to assess the threats to your system” and “design your system for security as well as functionality and performance” are hardly rocket science – in fact they should be core to our whole approach of doing IT within our organisations.

But if we look past the obvious stuff, the new guidelines do make some valid points – as one would hope given the vast range of organisations that contributed to it. (Along with the national cyber agencies mentioned already, a lot of commercial entities were also part of the production process, not least Amazon, Google, IBM, Microsoft and OpenAI).

One of my favourite points is that the authors put AI and ML into the same bucket. “We use AI to refer specifically to machine learning (ML) applications”, they say, and go on to defining what they mean by ML. Always nice to start by telling people what you mean by ML!

One of the most important things the guidelines remind us is that AI isn’t always the answer. A key requirement is that “you are confident that the task at hand is most appropriate addressed using AI”. How many people reading this have had the edict from on high – we need to do more with AI next year – with an undertone of “we actually don’t really understand what it is, but we keep reading that everyone’s doing it”. AI is like any technology – use it where it’s suitable, but don’t try to shoe-horn it in.

Getting back more to the security side of things, while many of the concepts that apply to AI systems are (as we’ve said) general security approaches, it can’t be denied that you have to give AI-specific consideration in each case. Take incident management, for example: just as a generalist incident responder needs training and practice to make a decent fist of IT-specific incidents, so an IT incident responder should have some awareness and training around incidents in an AI sense. The key thing to remember about AI is that what comes out of an AI system is less predictable (it’s been through a self-training mechanism that develops and modifies its behaviour as more data flows through) than what comes out of a traditional IT algorithm (which is largely deterministic and does what the developer told it to). So if an incident is going on, it’s harder to work back from what’s happening to what caused it to happen. The same concept applies across the other areas of IT: testing an AI system is harder than testing a “normal” IT system because outputs are harder to predict; it’s a relatively new concept so developer skills are thin on the ground; and it’s trickier for the security team to get to grips with AI systems because, like the rest of the IT team, both the concepts and the tech are new.

So, then: yes, the new guidelines for secure AI system development will tell you a lot of what you already knew. But it’s well worth a read, because it’ll definitely provoke a few thoughts and make you consider how AI might fit in your world (and how you’ll try to make sure what you make and/or deploy is secure). And if it doesn’t tell you everything you want to know, there’s a raft of links in there that will definitely help address that!

Another October has passed and with it another Cyber Security awareness month comes to a close. Islanders have had the privilege of a whole host of events scheduled throughout the month for the promotion of Cyber Security. We’ve learnt the importance of testing our incident response plans during a number of table top exercises, the value of the Cyber Essentials scheme with IASME and even how to rob a bank during our annual Cyber Security conference.

It's been an incredibly busy month for everyone within the industry and it is wonderful to see attendance at the events increasing each year. It’s also promising to see new faces at each event and the importance of Cyber Security being valued to those outside of those of us working within the industry. This is especially true of our annual Cyber Security conference, which many years ago would be isolated to a room full of Cyber Security professionals. What we see now at this conference is a wide range of attendees from many different areas within technology and some working outside, a positive sign that responsibility for Cyber Security is expanding within many businesses and becoming a core part of roles whether you have ‘Security’ within your role title or not.

Lastly a huge thanks must be said for all the speakers, hosts and volunteers who have been integral to ensuring a great month was had by all. A lot has gone into the organisation of each event and without those individuals who have spent considerable amount of their time preparing, they couldn’t have happened.

Now it’s time to start preparing for next year!

Like many people who work in cyber security, I was originally a mainstream IT bloke. Computing Science degree, service desk, IT writer, IT manager, CTO, head of IT operations, and so on. Then in the mid 2010s I joined the “dark side” and moved into cyber security.

Has my technical background helped me in my cyber security role? Heck yes. At the disappointing end of the spectrum, on a handful of occasions my technical knowledge has helped me cut through techies trying to bluff about how hard something is, or that yes, the firewall/switch/router/whatever is securely configured according to the company standard. At the more pleasant and acceptable end of things, though, I’ve been able to help the IT team fight their corner by confirming to the Risk/Compliance/Executive team that security problem X really is non-trivial to fix and that the time and cost really will be as the IT people are claiming.

Have I needed technical skills, though? I would argue probably not. Yes, they’ve been very helpful in a range of circumstances, but I’ve met plenty of senior security professionals who are very successful in their jobs despite being non-technical. So how have they managed it?

Simple: the technical stuff I mentioned a couple of paragraphs ago is just part of the story, but there’s another step that needs to be taken after the technicalities are understood. Take the example above where problem X has a specific time and cost impact if we’re going to fix it. All we’ve done is establish a few facts, and those facts came from the IT team in the first place – the security guy is simply saying: “Yeah, that sounds about right”. But these facts need to be formulated into some kind of risk quantisation, because what we care about is: do we need to fix it, how much of it do we need to fix, by when, and what’s the residual risk we can live with. That decision is above the pay grade of the security manager or CISO – it’s a risk decision, not a security one, to be made by those who hold the budget and the ultimate accountability.

The technical security person’s role in the examples I’ve mentioned highlights the core element that we require in an organisation: trust. If a non-technical CISO can rely on the IT manager, CTO, CIO or equivalent, they shouldn’t need a great deal of technical knowledge. Yes, I’m a huge advocate of security people having a solid grounding in the basic technicalities, but that’s primarily so they understand the basics of the concepts they’re reading or hearing and aren’t spending half of every meeting asking stuff like: “What’s a VPN?”. And yes, I’m sure many people reading this have seen cases where an IT manager has turned a horror story into a “nothing to see here” picture of good news for the CISO and the executive team. But the problem here isn’t that the CISO is non-technical (and the solution should be self-evident) and the inevitable outcome is that the horror story comes to light eventually, and probably far too late.

So no, you don’t necessarily need to be technical to be in cyber. Of course, in all but the smallest cyber team it’ll be necessary to have some people who are into the tech elements rather than the corporate, compliance or risk sides of things, but they will often (usually?) be in the minority. What you do need, however, is an excellent relationship with all the relevant parts of the organisation, and for that relationship to be one of mutual trust, openness and honesty.

Because when something goes pear-shaped, the joined-up organisation stands the best chance of dealing with it – no matter the level of technical capability of most of the cyber team.

Everyone likes a good whinge about governments and politicians. After all, if they didn’t exist then we’d have to find someone else to moan about.

The thing is, though, you might be surprised to read that I reckon there are some things that they do well. And in the case of the Jersey Government, one of those things is consulting people and groups about new guidelines and laws they’re considering implementing.

We in the Channel Islands Information Security Forum – and the Jersey cyber security community in general – are fortunate, in that we appear to be on the Government’s Groups That Might Have Something Useful To Say list regarding topics in and around cyber security. I look back to 2017 when the Government put out its consultation paper on the Cyber Security Strategy it was proposing to introduce. It was very enlightening taking part in group discussions about what the strategy might say, suggesting things that we thought might have been overlooked, questioning things that might have been a bit optimistic. We were similarly consulted by the Government when the newly minted UK Cyber Security Council put out its own consultation paper on the subject of obtaining a royal charter and awarding chartered certifications. And then, again, earlier this year, I sat in a packed meeting convened by the Government who wanted the opinions of CIISF members and the security community in general, this time around the new Cyber Defence Legislation that’s being drafted as I write this (and I wait with baited breath to see what the draft looks like when it arrives). And finally, the consultation that prompted me to choose this as a topic for this month’s LinkedIn feature – where I sat in a full CERT meeting room a few days ago as part of an interactive discussion about the new Telecoms Security Framework that’s being considered.

Will everything we asked for find its way into the final version of the Cyber Defence Legislation and Telecoms Security Framework? No, of course not – that’s not the way the world works. After all, if everyone listened to me the UK wouldn’t have left the EU, craft lager would be £1 a pint, and there would be on-the-spot fines for anyone who uses the term “Artificial Intelligence” without being able to define what it means. But looking back to the things that have been published over the years, it seems to me that our comments and suggestions have been listened to. And it feels like the same will apply to the Cyber Defence law – not least the bit that talks in the consultation document about mandatory reporting of any “potential security incidents/risk”, which pretty well everyone in the room had questioned and which seemed to elicit a “Hmmm, that’s a good point” response from the Government representatives.

Will the Government tweak its proposed legislation because they think that what the consultation groups have said is enlightening, better than their version, something they’d missed, and so on? Or will they do it because the meetings are minuted and if they roll out something completely daft that doesn’t work very well then those consulted can point at the minutes and say: “We told you so”? Frankly, it doesn’t matter – though of course I’d like it to be the former. What matters is that they have good reasons to accommodate the thoughts of the collective brains in the wider community, and a level of accountability should they choose not to take advantage of those thoughts.

And thus we arrive at the point of this article. Consultations can only work properly if the people being consulted turn up to the party. It’s a two-way street, and we all need to make the effort to go along to the consultation meetings, or to give our opinions electronically if we can’t be there in person. In a small community such as Jersey there’s always the risk of the loud, opinionated ones rocking up and having a good old rant while the quieter ones – who probably have equally valid opinions – aren’t heard. And it would be a shame for that to happen. Fortunately, in the cyber-related consultations I’ve been a part of, we’ve turned up in good numbers and from a good variety of sectors and specialisms, but we need to keep up the momentum.

For those who’ve not taken part in such consultations, I strongly recommend you keep an eye on the Government web site and the media. And if you see a consultation that relates to something you know about or are interested in, put up your metaphorical hand and say: “I’m in”. It’s not going to take infinite brain power or weeks of your time, and the value to the eventual result is potentially significant. Oh, and my experience is that the sessions are interesting and often provoke unexpected discussion and/or inform you of stuff that you weren’t previously aware of.

So, people, when we’re invited to do so, let’s make time, and make the effort, to be consulted.

Preparing your first cyber incident response plan

While attending our recent talks hosted by Bruce McDougall and Matt Palmer on the subject of incident response, it struck me that the overall maturity of businesses’ approaches to incident response can vary greatly.

Often, I speak to businesses regarding the overall maturity of cyber security posture assuming basics are in place – but that is often not the case. Cyber incident response plans are one of those basics that are generally missed. Most businesses generally focus on the avoidance of an incident – and while that is an envious position, generally it is not ‘if’ but ‘when’ an incident will happen. It is incredibly important to be prepared, have a plan, and ensure it is tested.

So where and how do you begin?

Don’t reinvent the wheel!

There are many frameworks, standards, and guidelines out there that provide detailed instruction in how to manage incident response. One of the most popular is NIST 800-61. The most important point here is that you do not need to start from scratch, there are even templates available for your business to download and adapt to suit such as the Incident Response Policy Template for CIS Control 17.

Utilising these ready-made templates will provide the basis for your plan, with the core steps required for the most basic forms of incident response.

Build a successful team

Your incident response team does not need to solely be made of security analysts, in fact it is recommended to not be a closed group. It is important for your response team to be made up of a cross section of resources across your business. Key roles to consider in the make up of your team are:

·      Incident Response Lead – your IR lead manages the overall running of your incident, keeping each member working within the process defined on paper. This role often has a good understanding of Incident Management and can lead a group of people and keep level-headed.

·      Security Analyst / IT Analyst – including a member of your Security or IT teams is a must. Often acting as a liaison between your more technical teams containing or remediating an incident, they will provide the much-needed subject matter expertise to the team.

·      Communications – a key member of the team, ensuring your plan includes the necessary processes for communications both internally and externally. Have a plan and resource to enact quick and clear communication so you can focus on the incident management.

·      Senior / Executive Leadership – ensure your incident management team has the necessary senior support to ensure quick escalation where necessary. This position can also provide support for specific roles, such as communication or spokesperson support.

·      HR / Health & Safety – always consider the people aspect, as the safety of people always comes first. Ensure someone is in the room to consider this as a priority and have processes in place to ensure the rotation of staff during incidents that may required management over a long period of time.

Once your team is assembled, ensure your roles and responsibilities are clearly defined and awareness shared. A successful team will be the one who knows their roles well.

Know your stakeholders.

It is important to know and understand your stakeholders during and after an incident. These are the individuals, entities or businesses that have an interest in your incident management status, such as regulators, insurers, customers, or suppliers. Have a clear plan for whom you need to communicate to and when, and be pro-active.

There are some stakeholders such as the Jersey Office of the Information Commissioner that may need to be informed under certain circumstances, within certain timescales.

Others such as customers and suppliers will want timely updates to alleviate concerns, if necessary. A proactive approach to communication can also support and avoid the potential floor of incoming communication that can cause issues with your incident response.

Post incident response

Don’t forget your post incident activities. When an incident is over and contained, and recovery is complete, we often want to take a sigh of relief and down tools. It is very important that post incident we take some time to complete activities that will greatly increase our response capabilities in the future: every incident is an opportunity to learn, so ensure you take your chance.

Ensure your have a lessons-learned process, review your incident response from a critical point of view. Include your team members within your lessons learned exercise and discuss what went right and what went wrong. Document your findings and implement a plan of action to improve.

Test, test test!

Don’t wait until a live incident to test your plan. Implement a schedule of testing, starting with the basics of a plan run-through. A plan run-through or review with all of your team present will give the option to raise awareness of the plan, and to include each individual’s role and responsibilities within. During this time each team member will have the opportunity to ask questions and prepare.

Once plan run-throughs are complete, progress towards a table top exercise. This type of exercise is a paper-based scenario that is created to role-play an incident, utilising your plan. There are a few ways to do this, the simplest being creating the scenario yourself and having a member of the team read through various prompts to similar an incident scenario. Another options available is the NCSC Exercise in a Box, which includes pre-built table top exercise for your teams to run through.

The important thing here is to test your plan, ensure it works. Any issues found, create an action plan to fix – then test again.

Summary

In summary, it may seem scary to begin the process of creating an incident response plan. However with a little bit of research there are many resources available online to support a speedy adoption of a simple plan. Your plan does not have to be complicated; anything is better then nothing. Create a plan, test and improve – then repeat the process.

Whenever we hear that an audit has been scheduled, it’s time to celebrate. We break out the Champagne and bunting and reflect on what a pleasure it is to open our office to a team of people who will do us a massive service by asking for obscure data items and ensuring we’re not over-burdened with free lots in our usually empty calendars.

Oh, hang about. Actually, I think the opposite might be true. The cry of “Oh, great!” is more of a sarcastic groan, issued through gritted teeth. Because even the least painful audit will take many hours, possibly over a number of weeks, and will generally result in a non-zero number of things to fix (or at least improve).

Let’s take a step back, though, and contemplate how we can make audits a less troublesome and negative experience. Because, believe it or not, it’s a perfectly feasible thing to wish for.

First of all, remember who is working for whom. In the vast majority of cases, it’s your own company that’s paying the auditors (or, normally, their employer) – so don’t be shy about making sure you get decent auditors. On two occasions in my career I’ve been saddled with unsuitable auditors, and both times they were sent packing with instructions to their employers to send someone better. The result in both instances was the arrival of replacements who were much better, with much better attitudes – and in fact one of them has become a friend.

Second, remind yourself that an auditor shouldn’t be hell-bent on giving you a poor audit. They are there to examine the effectiveness with which you’re operating your controls and complying with policies and regulations, and they should do so with an open mind. If you think the auditors are being unfairly biased toward negativity, say something (or exercise your rights under the previous point). They’re not there to roll over just because you’re upset they find a lot of issues, but they should at least be fair.

Third, you should also be fair. I’ve had ding-dongs (usually fairly polite ones) with auditors when I’ve disagreed with their findings. I’ve won some and I’ve lost some. The ones I’ve won were when I was able to explain the context of why we were doing something a particular way, or how they’d not quite understood something about the organisation which meant things weren’t as bad as they thought. Similarly, I’ve often capitulated when the auditor has explained the reasoning for the finding. Importantly, I’ve also had cases where something has been noted as an “observation” (that is, advisory rather than a must-fix) and I’ve been open and said: y’know what, I think that should be a finding. After all, sometimes you can get a bit of budget to fix a finding but not an observation.

Next, be open. If there’s a problem with your compliance with a policy or regulation, one of two things will happen: either (a) you tell the auditor about it; or (b) you keep your mouth shut and they find it themselves. Option (c) – stay quiet and they don’t find it – seldom works. If you’re honest and tell the auditor of your known issues, you get a massive boost of trust from them.

And to this former point, audits are a periodic (generally annual) thing, but surely you’re checking your own compliance through the year … aren’t you? If you’re doing your job properly, you should know where you have issues and have a plan for remediation of the problems you know about. If a shedload of negative findings at audit time comes as an utter, out-of-the-blue surprise, there’s something fundamentally broken with you or your organisation.

Next point: remember auditors are human too. Take them out for a beer, or for lunch, or for dinner. Get to know them socially. You might be surprised how normal they are (well, actually you almost certainly will be surprised). Don’t for a moment worry that they’ll think you’re trying to influence their findings or thought processes – a steak and a couple of pints is unlikely to sway any half-decent auditor. I’ve spent many happy evenings chatting about both work and personal stuff with auditors, and have often learned interesting things (chatting over a beer is a good chance to ask what other types of business they work with, or how they’ve seen other companies solve a problem that you’re facing).

And finally, why not consider becoming an auditor yourself? By which I mean maybe do a course. I did the ISO 27001 Lead Auditor course and exam, and it was an eye-opening experience that showed me the framework our auditors followed and demonstrated that once you’ve had things explained to you, there’s no rocket science, smoke or mirrors.

So yes, audits can be inconvenient and can reveal inconvenient truths about your policy compliance. But you should make the most of them and get the maximum value possible whilst being co-operative and open.

I once received an audit report whose executive summary contained the words “very pleasant experience”. We didn’t get an easy time, and we got a few findings to address, but we all made the most of it and the pain was minimal. So my advice to everyone who’s subject to audit is: embrace the opportunity and make the most of it.

An interesting evolution of the way we talk about Cyber Security has been happening over the past couple of years. The evolution I’m referring to is the predominance of the term ‘Cyber Resilience’ over ‘Cyber Security’. For the average person outside of the industry it may seem that these terms to describe the domain are interchangeable, however the reality is there is a distinct difference between each. This difference isn’t just within the definition but also the evolved approach to Cyber itself.

So, what do these terms mean? What are the differences? And what does this mean for us as we approach this within our working lives?

What is Cyber Security?

A quick internet search will provide us with many differently worded definitions of the term cyber security. My personal preference in describing the concept is simply ‘the use of people, processes and technology for the purpose of reducing the risk of cyber-attack’. This of course can be fleshed out to describe details but ultimately the concept is to reduce or stop cyber-attack.

What is Cyber Resilience?

An often repeated statement within the industry is that it’s not ‘If’ but ‘When’ you will be the victim of a cyber-attack. This doesn’t mean that the application of good cyber-security is futile, it is still important to ensure the reduction as much as possible of the chance of a successful cyber-attack.

This is where the concept of Cyber Resilience comes into play, which approaches the risk of cyber-attack by ensuring that appropriate measures are in place to ensure that if successful you can be prepared to respond and recover. Being cyber-resilient ensures that the path to green post a cyber incident is as smooth and painless as possible.

How does Cyber Security & Resilience fit together?

Cyber Security & Cyber Resilience are not mutually exclusive, in fact for a robust approach is to utilize both to improve your overall cyber strategy. Both concepts go hand in hand and also feed into an overall process of continual improvement.

Cyber Security includes controls for the protection of assets whether they fit within people, process or technology. It’s important we ensure appropriate controls are in place and often we choose these controls based upon suitable risk management.

Your approach to Cyber Resilience can then take the same risk management processes and applied controls, then assume the event of compromise. By doing so we can ensure that in the event of a successful cyber attack we have thought of and planned to respond and recover.

In practical terms, let’s consider the risk of a DDoS attack on a public internet facing firewall. We can assume in this scenario your business risk assessment has shown the risk of a DDoS attack is likely and the potential impact concerning. From a pure Cyber Security perspective, we can apply controls such as NGFW (Next Generation Firewalls), automated rulesets of the blocking of IPs and even minimizing the exposure of the device on the internet.

Then looking at this from a cyber resilience angle and assuming compromise. We can use concepts such as testing, whether it be penetration testing or table top exercises to attempt to simulate the results of a successful cyber-attack. Using the results of such tests, we can ensure additional controls are in place.

As an example a penetration test may prove that your NGFW may not be suitable for certain volumes of attacks, then for the improvement of cyber resilience – you may ensure appropriate sizing for said firewall, or outsourcing the protection to a third party cloud provider. Or another example may be that through a table top exercise, it may prove that you do not have an appropriate business continuity or disaster recovery plan to effectively response. Again for the purpose of improve cyber resilience, you can use these lessons learned to improve your overall cyber resilience.

In addition for this example in the unfortunate event of an actual real life DDoS, we can utilise the processes within Business Continuity or Disaster Recovery to feed lessons learned to improve our cyber security controls.

Summary

Cyber Security & Cyber Resilience are not new terms, nor do they include any new concepts. The evolution of these terms are a natural response to the overall approach to the risk of cyber-attack, of which the number and sophistication continues to scale up year by year.

What traditional cyber security teams will likely encounter as the industry evolves is the change in the make up of responsibilities within your areas. This is already happening for many and may not be unfamiliar, however responsibility for such things as Backups, Business Continuity and others may find their way into your security teams in the near future.

Whatever happens we’re likely to hear more and more reference to Cyber Resilience as we mature as an industry and it’s important we take it seriously within each of our own spheres of influence.

Information Technology (IT) and Cyber Security have become essential to any business or organisation in today’s digital age. The need for skilled professionals in this field has also increased with the rise of cyber threats. Many people interested in pursuing a career in cyber security may wonder whether it is better to gain work experience or complete a certification. While certifications can be helpful, there are several benefits to giving someone a chance to gain work experience in either Information Technology or Cyber Security.

First and foremost, work experience provides a hands-on approach to learning. In IT, hands-on experience is essential. It enables individuals to gain practical skills that cannot be acquired through a certification program alone. Work experience allows individuals to work on real-world problems and scenarios, developing their analytical and problem-solving skills.

Secondly, work experience exposes different areas of the Information Technology industry. The Information Technology landscape is vast, and there are several areas that one can specialise in, such as network security, information security, and application security, to name a few. By gaining work experience, individuals can explore different areas of cyber security and determine where their interests lie.

Thirdly, work experience provides networking opportunities. Information Technology & Cybersecurity professionals often work in teams; collaborating and communicating effectively is critical. By working alongside other professionals, individuals can develop their networking skills and build relationships to help them in their future careers.

Additionally, work experience provides a competitive edge. Employers often value work experience over certifications because it demonstrates that an individual has practical skills and can apply their knowledge in real-world situations. Work experience can make a candidate stand out from others who have only completed a certification program. Employers often look for candidates who are passionate about their work and are committed to their field. By gaining work experience, individuals can demonstrate their passion and commitment, which can help them stand out to potential employers.

We often hear that there is a skills gap or there need to be more skilled people in the market. Well, of course, there aren’t. These skills, or any skills, are things you learn by doing, getting your hands dirty, and making and fixing mistakes. You are not born with these skills.

Work experience provides a hands-on approach to learning, exposure to different areas of Information Technology & Cyber Security, networking opportunities, a competitive edge, and a chance to demonstrate passion and commitment.

Every organisation wants its employees to be passionate and committed. Still, they often miss these people in the hiring process because they have set the JD requirements too high, where you must have 10 years of experience and an ‘x’ number of certifications behind you before they even consider you for a role. I would love to see more organisations putting JD’s together that only detail the position they are looking to fill and have the candidate requirements as follows: ‘Must be willing to learn something new!’ I think they would be surprised at how many really good talented people are out there.