[email protected]   +1 (833) 3COLONY / +61 1300 733 940

Category Archives: Working in Hivint

Hivint’s 2016–17 Tech Year in Review

Over the course of the 2016–17 financial year, Hivint completed 117 technical security assessments ranging from source code reviews through to whole of organisation penetration tests for our clients.

One of our driving values is collaboration, so in this spirit, we wish to share statistics and observations about our year.

We hope that by sharing this information, we’ll provide an insight into the security assurance activities delivered by an Australian cyber-security consultancy. We also hope that over time, we’ll be able to identify and present trends in the evolving nature of assurance activities — supported by clear facts and figures as opposed to general observations.

Engagements

Our security assessments were delivered to Australian and international clients across a wide-range of industries, with the following chart providing the breakdown across industries.


It’s clear that our main clients for technical security assurance activities are positioned within the Finance, Government and Technology sectors, with approximately twice as many engagements performed in each of these sectors compared to the remainder. We believe that this can be attributed to:

  • The Finance industry being one of the more ‘security mature’ industries, and one that demands a high level of security assurance due to being a common attack target because of the potential of direct financial gain possible
  • The Technology industry maintaining a greater overall understanding of technical security risks and (similar to the Finance industry) demanding a high level of security assurance
  • The Government through its sheer size, and the need to obtain general periodic security assurance

The engagements completed varied greatly in the work effort, target and type of assessment performed. The 117 assessments undertaken ranged from short, single-day vulnerability assessments (intended to provide a limited, final quality assurance on a new system) to multi-month organisation wide penetration testing and vulnerability assessment activities. Engagements included configuration reviews, testing of hardware / IoT devices, mobile and web applications, wireless and network infrastructure, source code reviews and more, with web application testing being the most common assessment type (being the primary focus of 50 of the 117 assessments completed).

Findings

Through the 117 assessments undertaken, a total of 720 findings were identified. Findings which were deemed to not present a security risk (i.e. informational findings) are not included in this total.

To assess the risk of our security findings, Hivint employs an ISO 31000 aligned risk assessment framework, and employed common likelihood, impact and overall risk criteria. The table below provides a breakdown of the number and severity of findings.


The below chart provides the breakdown of the number of findings (from the Extreme down to Very Low risk severity) for each of the different industries.


Based on these ‘raw’ numbers, it’s clear that the majority of findings are presented as Low risks, with the number of findings tapering off as the risk severity increases. It is acknowledged however that these ‘raw’ numbers may be skewed due to the number and type of engagements performed for that industry — such that if the technology sector underwent the most engagements, then it seems reasonable that it would have the highest number of findings. To reduce this potential skew, the following chart has been provided which includes an average of the number of findings (for each risk rating) across the number of engagements completed for all clients in that industry sector.


With this normalised data, all industry sectors (except one) followed a fairly predictable pattern of having higher numbers of lower-risk issues, and lower numbers of high-risk issues. More mature industry sectors (such as Financial Services and Technology) showed a much more rapid drop-off as the risk of the issues increased. I.e. for these sectors, High risk issues as a proportion of all issues presented at a much lower rate, with the ratio of Low:High issues in Finance, Technology, Legal and some others being roughly 10–20:1. This is contrasted with Sports which is closer to 2:1.

We interpret this as a reflection of the focus over recent years in closing off the higher risk issues in industries such as Finance and Technology and the higher frequency with which tests have been completed against these systems.

A clear outlier in the total data set is the Retail sector which presented a higher average number of High risks than Low risks. Whilst on general we believe that the Retail sector doesn’t have the security maturity as sectors such as Finance and Technology, we expect that this level of High risk findings is an anomaly and we will be interested to review next year’s data to identify whether a similar ration of Low:High findings is present.

Monthly Breakdown

Across the year, there is a clear set of peaks by way of the number of security assessment engagements, and subsequently number of findings identified each month. The below chart presents the number of engagements and findings per month across the 2016–17 period.


The data in the above chart aligns with our experiences in working in this industry- something that we’ve seen in place for more than 10 years. The peak periods are the leadup to the end of the financial year and the calendar year, which we attribute primarily to:

  • The need to complete projects prior the end of a forecast cycle (which in Australia is largely prior to the Christmas holiday period — “I need the project in by Christmas”), and
  • The need to expend budget prior to the end of a financial cycle (which in Australia is primarily end of June).

We will be interested to see if the number of engagements across approximately November 2017 through to March / April 2018 increases as a result of entities seeking increased security assurance prior to mandatory data breach notification[i] requirements coming into effect in February 2018 (applicable to entities subject to the Privacy Act 1988).

Common Weaknesses

To categorise our findings, we follow the Web Application Security Consortium (WASC) Threat Classifications[ii] where possible. This allows us to remain consistent between engagements, and provides for a transparent view of categorisation.

Out of 720 findings across WASC categories, the top 10 WASC categories comprised 88% all findings. The below chart visualises the top 10 weakness categories that we found across the year:


The most common type of risk found was Application Misconfiguration, which is a fairly wide issue category — usually encountered when an application is not configured with security in mind — and includes issues such as a lack of security headers, or having default files disclose configuration details and application version information. The second most common was Insufficient Authentication, which can be seen when issues such as default credentials are in use, or if the application suffers from username enumeration.

Interestingly, the majority findings relate to the insecure configuration of the target system (application, operating system, network device etc.), or failing to keep the system patched to address known security issues. In a large number of our assessments, the targets are off the shelf systems that do not include any custom development by the implementing organisation, only configuration. Whilst it is recognised that some of these security findings are outside of the control of the implementing organisation (vulnerabilities in the software itself), in the majority of instances if the implementing organisation was to:

  1. Follow vendor implementation guidance for secure configuration of the system (as well as any underlying infrastructure), and

2. Keep the system patched,

Then many of these findings would not exist.

Conclusion

We are clearly not to the point where the need for security assurance activities through hands-on testing and analysis of systems is unnecessary due to security being sufficiently ‘baked in’ to the overall solution.

Anecdotally, we do see that organisations which invest in security earlier in the lifecycle (e.g. defining solution security requirements, performing security threat modelling, undertaking security design reviews and code assessments) result in fewer and less severe findings when implementation testing (such as a vulnerability assessment) is performed against the solution. Those that first introduce security into the project lifecycle through a vulnerability assessment a week before go-live are typically the ones with the greatest number (and higher severity) of findings.

Additionally, as the industry progresses to the use of more and more commoditised services (e.g. Software as a Service) and the number of bespoke applications reduces as a percentage of all deployments, we expect that the number of security ‘misconfigurations’ will increase as a percentage of overall findings due to a reduction in unique security vulnerabilities. We also hope that such a migration will also reduce the number of overall findings through our engagements, as an increasing number of ‘secure by default’ settings become ingrained into offerings.

Finally, we plan to keep an eye on developments across industry and relevant governing legislation such as the mandatory breach reporting in Australia, and impacts on Australian entities stemming from the EU’s General Data Protection Regulation. We expect that these macro-level changes will filter through the number and types of security activities (including security assessments) that are executed, and it will be interesting to see if next year’s data-set indicates any impact from these types of initiatives.

We hope that the data presented here has provided you with some useful insight into Hivint’s 2016–17 technical assessment activities. If you would like to see more material that we’ve shared from our engagements — such as security test cases, cheat sheets, common security findings and more — sign up for a free subscription to our collaboration portal at https://portal.securitycolony.com/register.


Contributors: Aaron Doggett, Sam Reid, Cameron Stokes, and Jordan Sinclair


[i] Introduced through the Privacy Amendment (Notifiable Data Breaches) Act 2017 and defined as the Notifiable Data Breaches scheme. Additional details here: https://www.oaic.gov.au/engage-with-us/consultations/notifiable-data-breaches/

[ii] http://projects.webappsec.org/w/page/13246978/Threat%20Classification

Hivint in the Telstra Business Awards


Hivint entered the Telstra Business Awards in early 2017, and after a rigorous selection process, won the Victorian New Business Award, and the Victorian Business of the Year.

Check out the acceptance speeches below:

Craig and Nick accepting the Telstra Victorian New Business Award.

Craig and Nick accepting the Telstra Victorian Business of the Year Award.

Some more photos from the evening, with hundreds of passionate people from all types of businesses in attendance.

The Hivint team in attendance

Craig tearing up (just a little)

Craig Searle’s heartfelt acceptance speech

Next are the National Telstra Business Awards, competing against some of Australia’s highest performing businesses. See you there!

Cybersecurity Collaboration

Establishing a security Community of Interest


Hivint is all about security collaboration.

We believe that organisations can’t afford to solve security problems on their own and need to more efficiently build and consume security resources and services. Whilst we see our Security Colony as a key piece to this collaboration puzzle, we definitely don’t see it as the only piece.

Through our advisory services, we regularly see the same challenges and problems being faced by organisations within the same industry. We also see hesitation between organisations to share information with others. This is often due to perceived competitiveness, lack of a framework to enforce sharing and fear of sharing too much information, along with privacy concerns.

We believe that it is important for organisations to realise that security shouldn’t compete between ‘competitors’, but instead against threats, and that working together to solve common security challenges is vital. We want to help make that happen. One such way — and the purpose of this article — is for a group of similar organisations to form a security Community of Interest (CoI).

This article outlines our suggested approach towards establishing and running a CoI, covering off a number of common concerns regarding the operation of such a community, and concludes with a link to a template that can be used by any organisation wishing to establish such a CoI.

Why is information sharing good?

Security information sharing and collaboration helps ensure that organisations across the industry learn from each other, leading to innovative thinking to deter cyber criminals. Our earlier blog post, Security Collaboration — The Problem and Our Solution, provides a detailed outlook on security collaboration.

We consider security collaboration as vital to making a difference to the economics of cyber-crimes, and as such we share what works and what doesn’t by making the output of our consulting engagements available on our Security Colony Portal.

However, we acknowledge that there are times when sharing could be more direct between organisations by forming a collective more closely — documents and resources could then be shared that are more specific to their industry (for example, acceptable use policies may be very similar across universities), or more sensitive in nature in a way that could make it unreasonable to share publicly (for example, sharing security related issues that may not have been effectively solved yet).

When does a Community of Interest work?

Sharing of information is most effective when a collective group is interested in a similar type of information. An example of this may be university institutions — while distinct entities will have different implementations, the overall challenges that each face is likely to be similar. Pooling resources such as policy, operating procedures, and to an extent metrics, provides a way to maximise performance of the group as a whole, while minimising duplication of effort.

When is Community of Interest sharing a bad idea?

Sharing agreements like a CoI will not be effective in all circumstances — a CoI will only work if information flows in both directions for the organisations involved. It would not be a suitable framework for things that generally flow in a single direction, such as government reporting. A CoI’s primary focus should also not be on sharing ‘threat intel’ as there are a number of services that already do this such as Cert Australia, Open Threat Exchange, McAfee Threat Intelligence Exchange and IBM X-Force to name a few.

How is information shared within a Community of Interest?

An important aspect of a CoI is the platform used for sharing between members of CoI. It is important to recognise the fact that platforms used will not be the same used across all CoI’s, each organisation will have unique requirements and preferences as to which platforms will be most effective in the circumstances. Platforms such as email-lists and portals can be effective for sharing electronically, however platforms like meetings (be it in person, or teleconference style) may be more effective in some cases.

What kind of information can be shared?

In theory, almost anything, however in practice there are seven major types of cybersecurity information suitable for sharing, according to Microsoft[1]. These are:

  • Details of attempted or successful incidents
  • Potential threats to business
  • Exploitable software
  • Hardware or business process vulnerabilities
  • Mitigations strategies against identified threats and vulnerabilities
  • Situational awareness
  • Best practices for incident management and strategic analysis of current and future risk environment.

Hivint recognises that every piece of information has different uses and benefits. Sharing of information like general policy documents, acceptable use policy, or processes that an organisation struggles with or perform well can uplift cyber resilience and efficiency among businesses. These are also relatively simple artefacts that can be shared to help build an initial trust in the CoI, and are recommended as a starting point.

What about privacy and confidentiality?

Keeping information confidential is a fundamental value for establishing trust within a CoI. To ensure this is maintained, guidelines must be established against sharing of customer information or personal records.

Information should be de-identified and de-sensitised to remove any content that could potentially introduce a form of unauthorised disclosure / breach, and limitations should be established to determine the extent of information able to be shared, as well as the authorised use of this information by the receiving parties.

How is a Community of Interest formed?

It is important to realise that organisations need not follow a single structure or model when setting up a CoI. Ideally, the first step is identifying and contacting like-minded people with an interest in collaborating from your network or business area. Interpersonal relationship between personnel involved in CoI is critical to retaining and enhancing the trust and confidence of all members. A fitting approach to creating such an environment is by initially exchanging non-specific or non-critical information on a more informal basis. Considering that sharing agreements like this require a progressive approach, it is best not to jump head first by sharing all the information pertaining to your business at the first instance.

Upon success of the first phase of sharing and development of a strong relationship between parties involved, a more formal approach is encouraged for the next phase.

Next Steps

We’ve made a Cyber Security Collaboration Framework available to all subscribers (free and paid) of Security Colony which can be used as a template to start the discussion with interested parties, and when the time comes, formally establish the CoI.

[1] ‘A Framework for Cybersecurity information sharing and risk reduction’ — https://www.microsoft.com/en-us/download/details.aspx?id=45516


Additional Information

There are a number of instances where cyber-security information sharing arrangements have been established around the world. The below provides links to a small number of these.

http://data.cambridgeshire.gov.uk/data/information-management/info-sharing-framework/cambs-information-sharing-framework.pdf

https://corpgov.law.harvard.edu/2016/03/03/federal-guidance-on-the-cybersecurity-information-sharing-act-of-2015/

https://www.enisa.europa.eu/publications/cybersecurity-information-sharing

jobactive Case Study


Meeting the jobactive security compliance requirements

Hivint has been involved with the jobactive program since early 2015, initially undertaking the required IRAP assessment for one of the approved third party IT providers, and since then working with many different jobactive providers to help guide them through the process towards achieving security accreditation.

This post provides an overview of the compliance requirements of the program, as well as suggested steps and considerations for any entity currently planning or pursuing compliance.

About the program

The Australian Government’s jobactive program, directed by the Department of Employment (‘the Department’) is an Australian-wide initiative aimed at getting more Australians working. Through the program, jobseekers are both aided in getting prepared for work (or back to work) and being connected with employers through a network of Employment Services Providers (‘providers’).

Under the program all providers are required to be accredited by the Department as being able to deliver — and continue to deliver — services in a manner that meet various conditions. One condition (defined in item 32 in the jobactive deed) relates to the protection of data entrusted to the provider by the Department in order to deliver these services; effectively extending many of the Australian Government security requirements that apply to the Department through to these providers.

The data security requirements that all providers — as well as third parties hosting jobactive data on behalf of providers — are required to meet have been drawn from two Australian Government publications and one law regarding the protection of information. The publications defining the security control requirements against which providers are required to be compliant with, as well as the number of controls drawn from each include:

jobactive Statements of Applicability

Rather than taking a big bang all or nothing approach — where providers are required to be compliant with all controls by a specific date — the Department has introduced a graduated approach to achieving compliance. This has been developed through the definition of three individual compliance stages defined within the jobactive Statements of Applicability (SoA), with the requirement for compliance phased across an approximate three-year period.

The perceived intent here is to start providers off with the need to establish a baseline security capability that is then matured with more advanced and complex controls over time. The overall timeframe for compliance, and number of controls in each stage and SoA include:


The below graph shows the breakdown of these SoAs as drawn from the three input documents. What is evident from the graph below is that SoA 1 covers a broad set of controls across most of the ISM security domains and the Privacy Act, providing a general security baseline for providers.

Progressing through the program (SoA2 through to SoA3) security becomes more focused in specific domains and extended to include more advanced and complex technical controls within the framework.


Assessment requirements

It’s easy to see that the lion’s share of the requirements have been drawn from the ISM, which reflects the Department’s focus on information security through cyber-security.

The Department has leveraged the existing register of security professionals already authorised to complete formal assessments of systems against the ISM for certification and accreditation by government bodies. The Information Security Registered Assessor Program (IRAP) list of assessors is maintained by the Australian Signals Directorate (ASD), the same body that is responsible for the ISM.

The Department has given providers the option to undertake a self-assessment for the first compliance assessment, but require formal assessments by IRAP assessors for stages 2 & 3. These assessments include:

  • The first assessment is considered a self-assessment, whereby providers completed their own against the controls defined in SoA 1, and report findings to the Department for review.
  • The second assessment is required to be completed by an IRAP assessor, with assessment coverage of controls defined in both SoA 1 and SoA 2.
  • The third assessment is also required to be completed by an IRAP assessor, and so long as the risk profile or environment hosting jobactive data hasn’t significantly changed, the assessment may be completed against the controls in SoA 3 only (we recommend validating this position with the IRAP assessor and Department prior to conducting this assessment).
  • From this point, the provider is required to undergo assessment no less than every three years — potentially sooner if the Department requests a new assessment based on factors such as a change in governance arrangements, changing cyber threats or other factors that change the IT security landscape for the provider.

Where to start

Achieving a level of compliance, acceptable to the Department against the full set of security controls reflected across the SoAs can be a daunting task for many providers. We’ve worked with a variety of providers, from small, single office not-for-profits, through to large Australian wide commercial providers and each has needed to invest considerable time and effort to achieve the target compliance posture.

However regardless of the size, scope and overall security maturity of the provider that we’ve worked with, the general approach that we’ve successfully employed with each has the same main principles and phases, being:

  • Phase 1 — Scope Definition, Reduction and Validation
  • Phase 2 — Risk and Control Definition
  • Phase 3 — Control Implementation & Refinement
  • Phase 4 — SoA 1 and 2 Assessment
  • Phase 5 — Control Implementation & Refinement
  • Phase 6 — SoA 3 Assessment

A high level overview of the first two phases is provided below.

Phase 1 — Scope Definition, Reduction and Validation

This is a crucial first step that is often overlooked by providers. We strongly believe that proper planning greatly increases your likelihood of an overall successful initiative, both financially and operationally; reducing the likelihood of unnecessary and wasteful investment, and clearly establishing the bounds for compliance. We recommend that providers undertake each of the following, and whilst not mandated, having an IRAP assessor engaged to assist through the process can also speed this activity up, and improve the outcomes considerably.

1. Establish your scope. It’s often not clear exactly what data is subject to the Department’s requirements (Is it only data retrieved from Employment systems? What about data provided directly from jobseekers? Data that is obtained from other providers? And so on…). Knowing what’s in scope and what isn’t can help ensure that you can focus your compliance efforts appropriately. We recommend that providers:

  • Identify jobseeker information coming into the organisation. Document the Employment provided systems where you retrieve or access jobseeker information, the method that you obtain it as well as the type of information that you retrieve.
  • Identify where you build on this information. Document instances where you build on this information through other sources- e.g. jobseeker provided information, and again, capture the type and method of information that you obtain.
  • Identify who you share this information with. Document instances where you share information with third parties in support of jobseeker services.
  • Define your business process. Capture the above processes together as a set of workflows, outlining the relevant actors, information types and actions performed.
  • Overlay these processes across your environment. Overlay these processes across your physical, personnel and IT environments — including those hosted by third parties, such as Department accredited entities, ASD certified providers, or any other entity (don’t forget to include support processes such as offsite backups, or remote connections from IT service providers into your environment).

2. Validate your scope. Engage with the Department’s Security Compliance team to discuss what you have established, and seek input as to whether you are able to remove certain entities, information types and processes from your scope. The Department may also be able to assist by providing upfront guidance on critical / high-risk issues with your practices (e.g. storing jobactive data offshore by a non-approved provider)

3. Define a plan to reduce your scope. This is an optional activity whereby a provider may wish to reduce or otherwise change their scope to reduce the compliance exposure. Some entities have taken the path to apply the controls to their entire business (as they are seen as good practice security controls — regardless of the data types that they are protecting), and other have reduced their scope by changing or consolidating systems and business processes utilising jobactive data.

4. Review the SoAs and remove controls that don’t apply. The SoAs contain a combined 409 security controls, however not all apply to all providers. So rather than investing in unnecessary compliance expenditure, documenting controls that the provider considers are out of scope, and including justification for them can save a lot of effort. For example:


5. Validate your scope. Following any documented proposal to reduce your environment scope and / or remove controls from the SoA, validation with the Department and / or your IRAP assessor is critical. Only once the revised scope has been validated should you implement the changes.

Phase 2 — Risk and Control Definition

Once the scope has been established providers are in a position to define and implement controls to meet the Department’s security compliance requirements.

Our immediate recommended next step is for providers to formally assess their security risk posture, and then begin to establish key overarching security artefacts that will govern their security controls.
This includes:

  • Document the Security Risk Management Plan (SRMP) — this document captures the various security risks to jobactive data within the providers scoped environment, as well as the controls in place and planned to be in place to mitigate these risks to an acceptable level.
  • Define the System Security Plan — this document is derived from the SRMP, the environment scope, and the Department’s SoAs and describes the implementation and operation of security controls for the system.
  • Define the security documentation framework — various documents which collectively detail the provider’s security controls. This typically comprises security policies, standards, plans and procedures.

We recognise that many providers have not previously needed to establish the majority of the above, and we suggest that you refer to the ISM Controls Manual for further detail describing each of the required documentation artefacts, or alternatively get in touch with an IRAP assessor to assist.

Phase 3 and Beyond

From this point, providers should be well positioned to implement the various controls defined, and then progress towards the required SoA 1 self-assessment, and subsequent IRAP assessments.

At this stage, providers may also wish to undertake a compliance gap assessment against the controls across the SoAs to help identify the overall compliance posture, and inform the prioritisation, as well as overall resourcing and investment in the compliance initiative.

Maintaining an IRAP Assessor (or alternatively, an individual with previous experience in adopting the ISM control framework) in an advisory capacity throughout this process* can also help in ensuring that the provider stays on track through the process.

Need a Hand?

Hivint maintains a team of IRAP Assessors and security consultants across Australia with extensive experience in Federal Government security requirements and the development and application of ISM security control frameworks and compliance strategies.

If you have any questions regarding the Department’s security compliance requirements, or if you may need a hand in working out where to start (or how to progress), please get in touch with us here.


Case Study by Aaron Doggett, Regional Director, Hivint

* To remove any potential conflict of interest, the IRAP Assessor engaged to perform the formal assessments must not also operate in an advisory / consulting capability to the provider.

Vendor Risk Assessment Tool

Our new addition to the Security Colony Portal.


Security Colony has released its “Vendor Risk Assessment” (VRA) tool, developed in conjunction with a major financial services client, which enables our subscribers to assess the risk posed to their internet facing sites, and receive a profile reflecting their cyber security maturity.

While seeing your own profile is empowering, the ultimate purpose of the tool is to enable you to gain better visibility over your suppliers. In Q2 this year, we will be releasing the ability for our paid subscribers to add additional vendors for tracking, to get a view of their third party risk.


The platform uses a range of free, open source and commercial tools to complete 17 distinct checks against a company’s online footprint, packaging this analysis up in an easy to use interface that details identified risks and providing an overall risk score and grade for the vendor.

What does it do?

There are two broad assessment categories completed by the VRA platform: malicious activity checks, and misconfiguration and vulnerability checks.

The data collected from these assessments is then analysed and presented in an easy to manage format, including:

  • Providing a risk-based score (out of 10) and a corresponding grade (from A to F)
  • Tracking the change in security risks over time
  • Providing clarity around the source of the calculation

Domain Risk Overview

Malicious activity checks

The VRA tool assesses the organisation for historic (or current) malicious activity, including:

  • Whether an organisation has had their domain blacklisted for spam
  • Whether an organisation has been identified as hosting malware on their domains
  • Whether an organisation has been identified as a source of phishing attacks
  • Whether an organisation has been identified as a source of botnet attacks

Malicious activity checks

Misconfiguration and vulnerability checks

The VRA tool assesses security misconfigurations and vulnerabilities, including:

  • Whether an organisation has a strong process for correctly configuring all their encryption (SSL/TLS) certificates
  • Whether an organisation uses strong email security technology (SPF and DMARC)
  • Whether employees of an organisation have used their corporate email addresses on external accounts, and whether they have then been the subject of a data breach
  • Whether an organisation has insecure (ie. unencrypted) ports open to the Internet

Security configuration and vulnerability checks

To demonstrate the system, scores were calculated for each of the ASX 100 companies. Analysed by industry, the average industry scores — out of 10 — were as follows:


Key findings of the analysis were:

  • The IT industry has the best average score, showing their understanding of the importance of consistent cyber security processes.
  • Telecommunications and Financial Services round out the Top 3.
  • Energy, Materials (including mining) and Industrials are less mature, reflecting the reduced focus they have placed on cyber security historically.
  • Health Care is in the bottom 4, a significant concern given the sensitivity of data held.

Just 3 companies in the ASX 100 received a ‘perfect 10’ — ANZ Bank, Link Group, and Star Entertainment Group.


The VRA tool is now live in the Security Colony (securitycolony.com) portal. Membership is free and any organization can see their own score after signing up.

The World Today

I originally wrote this message to try and give some perspective and comfort to the very diverse team within Hivint.

But given the great — and emotional — response, decided it should be shared more broadly. You may not agree with the political sentiment, and I respect that, but hopefully everyone agrees with the need to support each other through tough times.

Nick.


Hey Team,

I was motivated to write this after seeing my friend Mike Cannon-Brookes, one of Atlassian’s founders, put down the thoughts of he and co-founder Scott, in their blog article Your tired, your poor, your huddled masses yearning to breathe free…

The reality is that with the success their business has had, their voices will ring more loudly than mine, but equally I recognise the importance of everyone being heard, being vocal, and not sitting quietly while the world starts to burn.

I was fortunate enough to live in Boston back in 2013–14, and not far from my apartment was the Holocaust memorial, which included a version of Pastor Martin Niemöller’s (1892–1984) cautionary verse about the lack of conviction shown by those in German society who could change opinion, as the Nazis rose to power and started to progressively purge their enemies:

First they came for the Socialists, and I did not speak out — Because I was not a Socialist.

Then they came for the Trade Unionists, and I did not speak out —

Because I was not a Trade Unionist.

Then they came for the Jews, and I did not speak out — 
Because I was not a Jew.

Then they came for me — and there was no one left to speak for me.

To be clear, I’m not saying that Trump is Hitler, and I’m not saying a temporary visa ban is equivalent to the Holocaust. The point I’m making is in the power of that verse. I’m not a Syrian refugee, I’m not Mexican, I’m not a woman, and I’m not carrying the passport of an Islamic nation. But if I don’t speak out for them now, I can’t rightfully expect them to have my back when the system fucks me over somewhere down the line.

The immigration ban is not OK. Banning refugees is not OK. Walking back hard-won progress on reproductive rights is not OK.

We’re really fortunate in our team at Hivint to have 26 amazing people, and a level of diversity which for a small team is pretty extraordinary. Male, female, gay, straight, at least half a dozen or so religious belief systems, cat-people, dog-people, herbivores and omnivores, lots of weird and wonderful personality traits, and some great, original thought.

I just want you to all know that we also have a conscience. Yes, this is a business, but ahead of all of that, we’re all people. And Craig and I, and all the Leadership Team, genuinely care. Some of you will be more impacted by the current state of affairs than others. If you have any concerns, want to discuss anything, or just want a friendly ear to talk, feel free to grab us.

All bees are welcome here.

Nick

Joining the Hive

Insights into the cyber-security industry from some of Hivint’s junior bees


While tertiary institutions around Australia are striving to produce an increasing number of students equipped with cyber security expertise, the industry is often referred to as being in the midst of a ‘skills shortage’.

Meanwhile, Hivint has been in a period of substantial growth, with the team quite literally doubling in size from January to December of 2016. As part of that growth, we’ve brought on a number of graduates and industry newcomers with a variety of backgrounds and skill sets, who have quickly become an integral and valued part of our team.

With cyber security increasingly being seen as a desirable pathway for many of the brightest and best students in Australia (and around the world), we thought it would be apt to get an insight from our new recruits about what it took for them to be successful in joining Australia’s fastest growing cyber security consulting firm, the challenges they have faced, and advice they have for other people aspiring to pursue a career in cyber security.

Justin Kuyken — GRC Advisor

After 12 years cleaning swimming pools, I went back to university part time to study computer science at LaTrobe University — something I had an interest in since my school days. 6 years later in my final year, a network security subject piqued my interest, and after graduating I started absorbing as much information as I could find on this new-found passion.

After another year of reading all the books and using all the tools I could find to expand my knowledge in the area, I still hadn’t had any luck with my efforts to get a start in the industry. Finally, the persistence paid off when I heard back from Hivint, who spoke to me about joining their team as a graduate-level Governance, Risk and Compliance (GRC) advisor. 
While this was not what I originally had in mind, after some research, the role appeared to be an even better way into the industry as a beginner and to get a better understanding of how the security world really works. 
During the recruitment process, the Hivint team was impressed by the dedication and commitment I had displayed in my own knowledge development, having shown a clear passion for developing my own knowledge about any and everything security-related. They decided to bring me on board, and I have not looked back. I have loved my time as part of the company, despite not being the ‘1337’ hacker I originally thought I would be when I started out on this whole path!

In summary, my advice to other aspiring graduates looking for a start is to show initiative to prospective employers — find a way to demonstrate that you are passionate about joining the industry and about continual improvement (e.g. through independent studies and learning), as these are valuable skills even on the job. In addition, be persistent about looking for opportunities — it may take some time, but the payoff for me by getting a foot in the door at Hivint has been well worth it.

Lumina Remick — GRC Advisor

After completing a Masters in Project Management at Bond University, my original plan was to return to working with circuits and microprocessors given my original background in Electronic and Communications Engineering. Little did I know an interesting career change was waiting for me.

In the final semester of my studies, I interned for an asset management company. My job primarily focused on implementing and tailoring their risk management policy and procedures to suit their business needs. However, I also had the opportunity to work on their IT security policies. This experience — together with my interest for risk management — piqued my interest for a career in cyber security.

Coincidentally, the company I worked for was Hivint’s client, so I had a sneak peak of Hivint’s work even before I became a part of the Hive. I believed the right place to further my new-found interest was at Hivint, so I religiously started following them on social-media platforms looking for a way in. 
When they advertised for a graduate GRC advisor role. I jumped at the opportunity, and there has been no turning back.

As a beginner, this role has been an amazing way into the industry and a great learning experience. I’m constantly learning new things and have come to realise there is no such thing as ‘knowing it all’ in security. I must admit that Google has quite often been my best friend through the whole experience. 
Working with some of the best people in the industry has inspired and made me love my time at Hivint.

My advice to any aspiring graduates is to do your research on who are the companies in the industry hiring, and then make sure you know as much as you can about them and keep a regular eye out to see if they are looking to fill new roles. The fact you have done your research and shown an interest in them will stand you in good stead should you land an interview!

Sam Reid — Technical Security Specialist

I took the common route through university, completing a Bachelor of Science in Cyber Security at Edith Cowan University. The first thing I’ll say is that working in the industry is more about client relationships and working with clients (particularly to help them understand their security risks and which ones are appropriate to accept, and which ones are not) than I originally thought. Those boring risk and standards units at uni turned out to be important when assisting clients manage their exposure!

Penetration testing is the real deal and it’s seriously cool. The exposure and range of things you get to test and ‘break’ to help clients identify security holes will live up to your expectations — guaranteed.

My advice to aspiring grads — with the constant stream of new information, trends and events in this industry — from new vulnerability disclosures, ongoing data breaches, growth in IoT devices, and DDoS attacks, it’s easy to be left behind when you’re starting out. Try to keep your passion up by doing security-related things you enjoy in your own time when you can. Capture the Flag (CTF) events, security research, bug bounties, secure software development not only keep you interested — they keep you interesting! A challenging CTF you recently completed could make a great story to tell during an interview.

As a case in point, I was hired as a junior security analyst straight from university and while I hadn’t heard of Hivint (they were only 12 people back then), the regional director had heard of me having attended a presentation I did on identity theft at a local security meetup. In my opinion, engaging with the community and making yourself known in the field (for the right reasons!) can really kick-start your career and put you ahead of the other graduate job seekers.

Oh, and lastly, be mindful of how you refer to your occupation as a ‘penetration tester’. My Mum proudly told the extended family that I was a “computer penetrator” last Christmas. No Mum. Please don’t ever say that again.

John Gerardos — GRC Advisor

I always knew I’d enroll into a Computer Science degree and work in technology. I originally worked primarily in support/systems administration and network engineering. My last few years as a network engineer had me either living in datacenters or designing and installing wireless access across large campuses in preparation for the explosion of BYOD (bring your own device) policies.

It very quickly became apparent that securing networks from the risks inherit in BYOD as well as the emerging Internet of Things was going to be a very interesting and expanding area. After working closely with the security team on several projects, I decided that is where I wanted to move my career.
So back to university I went! Along with my usual studies at the Masters of Applied Science (Information Security and Assurance) at RMIT, I learned about Ruxmon, a free security meetup that was run once a month on-campus. I immersed myself in the “Security Scene”, began attending Ruxmon, assisting with the organisation of the meetup as well as stepping up to lead the Information Security Student Group at RMIT University. I made it my goal to attend as many security meetups as possible and learn from the experts, which I found very rewarding and something that also helped cover and re-enforce some of the material learnt in my studies.

My university often ran industry networking events and I happened to bump into a couple of Hivint people at one I spoke at. I had not heard of Hivint at the time but it very quickly became apparent that it would be a cool place to work — so I kept it in mind and was excited when I saw them advertise for a graduate role.

The past 6 months on the Hivint team have been amazing! While I already had industry experience, this was my first consulting role and I had to very quickly learn how to manage my time across clients and get up to speed with the IT infrastructure of each client that I was working at. I also quickly found out that it’s not just the technical skills that are important — you need to be a great communicator and take the time to understand each individual client’s business so that you can tailor a solution for them.

My advice to students looking to enter the industry is to network with others and immerse yourself in the field. We are lucky that there are so many high quality free security meetups around the place — make the time to attend the ones that look interesting to you and have a chat to the people there. Follow up by doing your own research on anything that sounded interesting during the meetup, as well as joining in on relevant CTF events. Security people are happy to share the knowledge around and the best way for a student to learn outside of university is to be active in the community, attend relevant meetups and engage with the experts.