Rotting fish: The need to improve cyber culture

elevenM’s newest recruit Jasmine Logaraj shares her thoughts on improving the culture within the cyber security industry, and how that will help to defend cyber threats.

This week, I had the opportunity to attend The CyberShift Alliance’s discussion “Addressing workplace culture in the cyber security sector.” The CyberShift Alliance is a collaboration between several associations including ISACA SheLeadsTech, FITT, CISO Lens, AWSN, the Australian Signal Directorate, AustCyber, ISC2 and AISA, DOTM, EY and Forrester Researcher, with the goal of addressing culture change within security. This alliance formed from an earlier International Women’s Day event run by AWSN and ISACA.

The purpose of the discussion this week was to raise awareness of toxicity in the cyber security industry. Speaker Jinan Budge, Principal Analyst at Forrester, described the main reasons for toxicity in the industry as being lack of organisational support, ego, and low leadership maturity.

Poor workplace culture is preventing good talent from joining the industry and making it harder to retain it. It is hindering the quality of work and preventing us as a nation from tackling cyber threats in the most inclusive, collaborative and, therefore, the most optimum way.

I asked Jinan and the panelists during the Q&A session to elaborate on the idea of toxicity being a barrier to young talent. Panelist Jacqui Kernot, Partner in Cyber Security at EY, said the reason it was hard to hire good talent was not because of a shortage of professionals with STEM skills, but because the industry needs to become a better place to work.

As cyber security professionals, we need to make this industry a more exciting and happier place. When recruiting, employers need to consider not only whether the employees are properly skilled, but whether they are the right fit for a good workplace culture, and in turn, whether their company is worthy of such wholesome candidates. Knowledge can be taught. Personality cannot.

Another interesting point raised during the discussion was the inability to speak out about bad behaviour in the cyber security industry. Jinan surveyed her professional network and found that 65% of respondents voted it to be “career suicide” to speak up about workplace problems, highlighting a fear of potential punishment for doing so. 

Changing this consensus relies on us as cyber security professionals leading the way. As Jacqui pointed out: “the fish rots from the head.” It is not a HR problem, but something to be fixed at the leadership level and not denied or swept under the rug. If companies do not address these problems, they will continue to lose good talent, and in turn waste money, time, and effort, leaving them with fewer employees and a lessened reputation. Akin to our efforts to create a security-focused culture in our clients, at elevenM we believe good workplace culture similarly requires an effort to foster shared values through leadership and role-modeling.

I am grateful that there are individuals such as Jinan, Jacqui and James working in my industry who realise the importance of fostering a good workplace culture. With leaders like these, I remain hopeful for the future.

Pete was right (but just this time)

By Arjun Ramachandran

Pete’s a hardened security professional. He’s been in this game for over 20 years and has the battle scars of many cyber uplift and remediation programs. He feels the pain of CISOs fighting the good fight.

I’m a former journo. Even though I’m no longer actively reporting, the craft matters to me and I get defensive and outraged in equal measures about the quality of print news.

Pete and I butted heads in recent days over the reporting of the NSW Auditor-General’s (AG) report into Transport for NSW and Sydney Trains.

The AG report, and much of the media coverage, was overtly critical. A “litany of cyber security weaknesses [identified in] a scathing review” was how the SMH described it.

Pete wasn’t overly happy about the coverage, feeling both the media reporting and the AG report to be unfair, particularly in the context of how organisations actually go about improving their cyber posture (more on this later).

While I defended the reporting as – for the most part – being a fair and straight write-up of the AG report, I have to concede that on the bigger point Pete was dead right.

There’s a problem in our industry, and in broader society, with how we often talk about and respond to reviews of organisations’ security programs. It’s not that we’re quick to talk about deficiencies that don’t exist or that aren’t serious, but that the way these reviews are presented drives a response and conversation that is counterproductive to good security outcomes.

There are no perfect security programs, or organisations with perfect security. The threat landscape changes daily and security uplifts require complex whole-of-organisation changes that necessarily take a long time. Even in the most mature organisations, “good security” is a work in progress, with gaps continuously identified and addressed. Any detailed review will find holes and inadequacies.

To be clear, this is not an argument to take lightly the adverse findings of a review. Arguably, these findings are a large part of why we do reviews, so that a measured and constructive response to them can lead to improved security.

But too often in our journeys at elevenM we see instances where the supercharged or out-of-proportion delivery of adverse findings leads to an equally supercharged response (sometimes in the form of its own large remediation program) that sees a sizeable redirection of resources, and ultimately the deferral or interruption of well-considered strategies or critical uplift projects.

We found it particularly uncomfortable that the AG report was based on a red team exercise. A red team exercise – where “authorised attackers” (in the words of the AG report) are given permission to try and break into systems – will always find security flaws. These exercises are typically conducted expressly to provide insights to security teams that they can learn from. To broadly publish those findings in the tone and manner that the AG report has done didn’t strike us as constructive.

Of Mice and Coin

elevenM’s Peter Quigley takes a closer look at what Australia can do in the face of a modern scourge – ransomware – as governments up the ante against the threat.

Plummeting winter temperatures in Australia have led to an unexpected threat for car and home owners: rats and mice. Like most of us, these rodents are trying to find a place to take refuge from the cold and the resulting damage has been significant.

The scale of this threat has led major insurers to reject many claims made, stating that their insurance only protects against vermin infestation as a flow-on effect from a fire or flood.

As a risk person, I have always found the insurance industry interesting. At its core, it is a system which derives profit from the analysis of risk data. This is why I keep an eye on what the industry is saying about cyber security.

Like homeowners in Australia, companies around the world are now having insurance claims rejected – not for vermin but for infestation of a different kind: ransomware.

As you will have undoubtably read, ransomware incidents have significantly increased over the past year. The reasons for this have been well reported and we won’t delve into them here. What I want to talk about is what happens to a cyber risk when, like vermin infestation, it becomes uninsurable?

If companies are not able to insure against a potential risk event, then they have two options: (i) accept the risk and wear the cost of that event should it happen or (ii) not engage in the practices which may lead to that risk event. In the case of ransomware (and most cyber threats), given the digital nature of every business today, the latter is not a viable option. So, we are left with the former – that is, taking the position of, as we say in Australia: “She’ll be right”.

If, however, businesses begin to fold and the broader economy is impacted, there’s a case to be made that the government needs to step in. In Australia, we are seeing building momentum as ransomware is yielded as a political stick – most recently by Tim Watts, Australia’s Shadow Minister for Cyber Security, calling for A National Ransomware Strategy. Ransomware was also on agenda at the G7 summit in London last weekend, with various commitments made to fight the threat collaboratively.

What governments can do to combat this technical and geopolitical threat in real terms is unknown. Mr Watt’s strategy contemplates a variety of measures including increased law enforcement, crackdowns on rogue bitcoin exchanges and various sanctions.  

The strategy also advocates for Australian organisations to develop a reputation for being less likely to pay ransoms (through imposing controls on ransomware payments), so that attackers’ return on investment for targeting Australian organisations might fall in comparison to those in other countries. While making yourself a less attractive target is a common and legitimate strategy in cyber security, I tend not to agree with this approach to ransom payments. Due to the random nature of ransomware attacks (often enabled by automated services scanning and prodding IP’s across the internet) it seems likely to me that Australian organisations will continue to be heavily impacted by ransomware – regardless of policies that limit or regulate their ability to pay ransoms.

As noted earlier, ransomware is both a technical and geopolitical problem. Looking at both these aspects in detail and asking what can be done, I always arrive at the following:

  • Technical – Ultimately, cyber criminals are most likely to move on if they encounter mature cyber defences. As done in Singapore, Australia should mandate a minimum set of cyber security controls for all critical infrastructure as part of current changes being considered to security legislation. Outline what those controls are and encourage private businesses to adopt those controls. The Australian Government should publish threat data on recent ransomware events to support those charged with the operation of cyber controls to update as required.
  • Geopolitical – Not to appear too cynical, but I maintain low expectations on the current and immediate impact of geopolitical efforts on the ransomware landscape. It’s widely believed that ransomware gangs operate with impunity in some jurisdictions, despite those jurisdictions agreeing to international norms. As these geopolitical efforts slowly gather pace, it’s all the more reason to enhance the defensive maturity of organisations in the meantime.

This is just my view. In the words of John Steinbeck, “Guy don’t need no sense to be a nice fella.”

Patch me if you can: key challenges and considerations

In this third and final post of our series on vulnerability management, elevenM’s Theo Schreuder explores some of the common challenges faced by those running vulnerability management programs.

In our experience working with clients, there are some recurring questions that present themselves once vulnerability management programs are up and running. We outline the main ones here, and propose a way forward.

Challenge 1: Choosing between a centralised or decentralised model

Depending on the size of your organisation, a good vulnerability management program may be harder or easier to implement. In a smaller organisation it usually falls to a single security function within the IT team to provide management of vulnerabilities. This makes it easy to coordinate and prioritise remediation work and perform evaluation for exemptions.

However, in larger organisations, having individual systems teams all trying to manage and report on their vulnerabilities makes it difficult to manage vulnerabilities in a holistic way. In these scenarios, a dedicated and centralised vulnerability management team is necessary to provide governance over the entire end-to-end cycle. This team should be responsible for running scans and providing expertise on assessment of vulnerabilities as well as providing holistic reporting to management and executives.

The benefit of a dedicated vulnerability management team is that there is a single point of contact for information about all the vulnerabilities in the organisation.

Challenge 2: Ensuring risk ownership

To avoid cries of “not my responsibility” or “I have other things to do” it is important to establish who owns the risk relating to different assets and domains in the organisation, and therefore who is responsible for driving the remediation of vulnerabilities. Without a clear definition of responsibilities and procedures it is easy to get bogged down in debates over responsibilities for carrying out remediation work, rather than proceeding with the actual doing of the remediation work and securing of the network.

Furthermore, in our experience there are often different responsibilities with regards to who patches what in an organisation. As mentioned in our previous post, often there is a distinction between who is responsible for patching of below base (system level) vulnerabilities and for above base (application level) vulnerabilities. If these distinctions, and the ownership of risk across these distinctions, are not clearly defined then the patching of some vulnerabilities can fall through the cracks.

Challenge 3: Driving risk-based remediation

The importance of having an organisation-wide critical asset register cannot be overstated. From the point of view of individual asset owners, their own application is the most critical….to them. It is important to take an approach that measures the risk  of an asset being exploited or becoming unavailable in terms of the business as a whole, and not just in terms of the team that uses the device.

In the same way, security risks, mitigating controls and network exposure must be taken into account. From a risk perspective, an air gapped payroll system behind ten thousand firewalls would not be as critical as an internet-facing router that has no controls in place and a default password that allows a hacker access into your network. Hackers don’t care so much about the function of a device if it allows them access to everything else on your network.

To recap …
We hope you enjoyed the series on vulnerability management. For a refresher, you can find links to all the posts in the series at the bottom of the article. In the meantime, here are our 5 top steps for a good vulnerability management program:

  1. Get visibility quickly – scan everything and tailor reports to different audiences.
  2. Centralise your vulnerability management function – provides a holistic picture of risk to your entire network and supports prioritisation.
  3. Know your critical assets – understand their exposure and prioritise their remediation.
  4. Get your house in order – have well defined and understood asset inventories, processes and risk ownership.
  5. Automate as much as possible – leverage technology to reduce the costs of lowering risk and allow you to do do more with less resources.

Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations

Patch me if you can: the six steps of vulnerability management

This is the second post in a three-part series on vulnerability management. In this post, elevenM’s Theo Schreuder describes the six steps of a vulnerability management program.

In the first post of this series, we explored why vulnerability management is important and looked at key considerations for setting up a vulnerability management program for success. In this post, we’ll step you through the six steps of vulnerability management.


The six steps of vulnerability management

The six steps of vulnerability management [Source: CDC]

Let’s explore each step in more detail.

  1. Discover vulnerabilities

The most efficient way to discover vulnerabilities is to use a centralised and dedicated tool (for example, Rapid7 InsightVM, Tenable, Qualys) that regularly scans assets (devices, servers, internet connected things) for published vulnerabilities. Information about published vulnerabilities can be obtained from official sources such as the US-based National Vulnerability Database (NVD), via alerts from your Security Operations Centre (SOC) or from external advisories.

Running scans on a regular basis ensures you have continuous visibility of vulnerabilities in your network.

 

2. Prioritise assets

Prioritising assets allows you to determine which remediation actions to focus on first to reduce the greatest amount of risk within the shortest time and with least budget.

Prioritisation of assets relies on having a well-maintained asset inventory (e.g. a Central Management Database or CMDB) and a list of the critical “crown jewel” assets and applications from a business point of view (for example, payroll systems are typically considered critical assets). Another factor to consider in determining prioritisation is the exposure of an asset to the perimeter of the network, and how many “hops” the asset is from an internet-facing device.

 

3. Assess vulnerability severity

After devices are scanned, discovered vulnerabilities are usually be assigned a severity score based on industry standards such as the Common Vulnerability Scoring System (CVSS) as well as custom calculations that — depending on the scanning tool — take into account factors including the ease of exploitability and the number of known exploit kits and plug-and-play malware kits available to exploit that vulnerability. This step can also involve verifying that the discovered vulnerability is not a false positive, and does in fact exist on the asset.

 

4. Reporting

When creating reports on vulnerability risk, it’s important to consider different levels of reporting to suit the needs of different audiences. Your reporting levels could include:

  1. Executive level reporting
    This level of reporting focuses on grand totals of discovered vulnerabilities and vulnerable assets, total critical vulnerabilities, and historical trends over time. The aim is to provide senior executives with a straightforward view of vulnerabilities in the network and trends.
  2. Management level reporting
    For individual managers and teams to manage their remediation work, it helps to provide them with a lower-level summary of only the assets they are responsible for. This report will have more detail than an executive level report, and should provide the ability to drill down and identify the most vulnerable assets and critical vulnerabilities where remediation work should begin.
  3. Support team level reporting
    This is the highest resolution report, providing detail for each vulnerability finding on each asset that a support team is responsible for. Depending on the organisation and the way patching responsibilities are divided, splitting out reporting between operating systems (below base) and application level (above base) can also be advantageous as remediation processes for these levels can differ.
A sample management-level vulnerability report generated using Tableau

 

5. Remediate vulnerabilities

“The easiest way to get rid of all of your vulnerabilities is to simply turn off all of your devices!”

– origin unknown

Remediation can take a variety of forms including but not limited to changing configuration files, applying a suggested patch from the scanning tool or even uninstalling the vulnerable program entirely.

There may be also be legitimate cases where a vulnerability may be exempted from remediation. Factors could include:

  • Is the asset soon to be decommissioned or nearing end-of-life?
  • Is it prohibitively expensive to upgrade to the newest secure version of the software?
  • Are there other mitigating controls in place (e.g. air-gapping, firewall rules)
  • Will the required work impact revenue by reducing service availability?

 

6. Verify remediation

Are we done yet? Not quite.

It doesn’t help if — after your support teams have done all this wonderful work — your vulnerability scanning tool is still reporting that the asset is vulnerable. Therefore, it is very important that once remediation work is complete you verify that the vulnerability is no longer being detected.

Stay tuned for the third and final post in the series, in which we discuss common challenges and considerations for a well-functioning vulnerability management program.


Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations