Creating a good security culture

This article introduces the concept of a security culture and provides guidance on how you can positively influence and evolve the culture in your organisation.

According to ENISA “Cybersecurity Culture refers to the knowledge, beliefs, perceptions, attitudes, assumptions, norms and values of people regarding cybersecurity and how they manifest in peoples behaviour”.

Every organisation has a security culture whether this is considered to be good or bad. Security culture is intertwined with organisational cultures and is shaped by messaging across all-levels of the organisation.

Large organisations are unlikely to have one culture. This will often differ across the organisation within different functions, departments, entities, business lines, offices, and jurisdictions. This cultural variation creates a challenge when seeking to communicate security messages and drive behavioural change as the message will be subject to differing interpretations.

Having a good security culture is fundamental in helping you to deliver an effective security programme within your organisation. This is key to building a good security foundation and will increase the probability that your initiatives deliver positive outcomes for the organisation.

Culture takes time and a concerted effort to evolve and must be formed with staff rather than being imposed upon them.

What does a good security culture look like?

A healthy or positive culture will actively contribute to support and enable the business to achieve its goals and objectives. To achieve this, you need staff to:

• Remember the things they are supposed to do for security and do them at the right times and in the right circumstances;
• Prioritise doing things in secure ways;
• Know how to report any concerns or suspicious activity and feel empowered to do so;
• Question processes in a constructive manner;
• Contribute to shape security policy;
• Understand the importance of cybersecurity measures and what they mean for the organisation;
• Understand risk associated with their day-to-day activities;
• Know and be confident in the mitigation and handling of risk.

What does a bad security culture look like?

A poor or negative culture will undermine efforts to manage security risk and has the potential to hinder the operation of the business. A negative security culture can result in:

• Staff not reporting any concerns or suspicious activity through the fear of blame or reprisal;
• Staff bypassing security tasks, taking unnecessary or high levels of risk or seeking to cut corners;
• Staff being cynical about security often due to a lack of influence to deliver the outcomes for which they are accountable;
• Staff only seek to do just enough;
• Company leaders not following the rules or seeking exceptions or special treatment;
• Staff not engaging with the security team or not contributing to security initiatives / programmes;
• Security team members feeling undervalued and separated (isolated) from the rest of the business;
• High attrition rate of security staff.

What blockers exist to developing a good security culture?

There are a multitude of factors that will hinder delivering a good security culture. These factors need to be addressed to support building the foundations for delivering a good culture of security:

• Security budgets are not keeping pace with the rising threat level;
• Staff do not feel their contributions are considered or valued;
• Staff lack the knowledge or confidence to do the right thing;
• Security is too insular and focused in a silo (such as technology) creating a boundary between security and the wider organisation;
• Rules make it hard for people to do their jobs encouraging staff to find workarounds or unofficial ways of working;
• Security seen as a blocker rather than an enabler;
• Leaders fail to lead by example;
• Operating a blame culture.

How can you influence security culture?

It is important to note that in general people want to do the right thing. There are often influencing factors involved that can inhibit staff following the desired security behaviours. Through understanding the behaviours, you can design and deliver targeted behaviour interventions that can help to overcome inhibiting influences.

The following are some examples of positive changes that you can make to support the development of a good security culture within your organisation.

Recognise that people are integral to successful security

Support people to get their job done as effectively and securely as possible. Develop capabilities and cues to make delivering secure behaviours easy. The less resistance to delivering a change in behaviour the easier it will be to support in the development of security as a habit.

Security Education, Training and Awareness (SETA)

Commit resource to the delivery of your SETA programme. Utilise the wealth of available resources to help you implement and deliver an effective programme. If you’re unsure what level of resourcing you require or what an effective programme looks like a good place to start is by reviewing the latest SANS Security Awareness Report and SANS Awareness Planning Kit.

Security as a business enabler

Support the business in achieving its goals and objectives. Enable people through helping them to effectively manage security risk. This will encourage staff to engage with the security team rather than finding ways of circumventing them.

Lead by example

The board and senior management need to lead by example and champion security. People will look to the leadership to provide an example. Ensure they receive tailored and targeted training, awareness and reporting. Help them to understand and manage the security risk to the business whilst enabling in the delivery of the organisational goals and objectives.

Avoid a culture of blame

Focus on the enforcement of good security behaviours through positive acknowledgment. Measure individuals progress and recognise their effort and improvement. Understand the root cause of bad security behaviours and design interventions to help address them. Fostering a culture of blame will encourage people to protect themselves often at the detriment of the organisation.

Make policies and standards fit for purpose

Engage with stakeholders from across the organisation. Be willing to recognise and address where they aren’t fit for purpose or are having a detrimental effect on peoples work. Support people to perform their role effectively and securely. If people don’t feel they are fit for purpose they are more likely to feel it is acceptable to bypass them.

Summary

Culture is developed at all levels of the organisation but needs to start from the top through the championing of security and cascading down through the organisational structure.

Assess the security culture in your organisation and understand what blockers exist in developing a good culture. Understand the root cause of these blockers and design initiatives / interventions to overcome them.

You can positively influence the security culture in your organisation but be careful to plan for this to take time and a concerted effort to deliver. Culture is something that needs to be managed and sustained over a prolonged period.

Further reading

There is a wealth of readily available information on developing a culture of security. The following are well worth reading to support you in the development of your own security programme:

• ENISA Cyber Security Culture in Organisations
• NCSC You Shape Security
• KnowBe4 Security Culture Report

Keeping track of application security flaws

This article provides a granular view into how to track and visualise application security flaws. It builds upon a previous article that provided a high-level overview of how to keep track of your application security posture. We'll do a deep dive into a few metrics identified within the original article. This will help you to understand how to visualise the metrics and what to look out for when analysing / trending the data.

Before getting started its important to be aware that garbage in (flawed input) will lead to garbage out (flawed output). Ensure the flaws identified by your security controls are genuine. A combination of false positive (incorrectly identify a vulnerability) and false negative (incorrectly identify that a vulnerability does not exist) will distort your findings.

Reporting on flawed data can be particularly problematic as you may incorrectly prioritise and resource unnecessary mitigations or fail to act in situations where mitigations are required.

Finding / Flaw Creation Rate

Track the rate of newly created flaws over a set period. Flaws are often introduced due to:

• The deployment of changes;
• Newly identified vulnerabilities in utilised technologies;
• A failure to maintain technologies or adhere to security best practice standards.

What to look out for

Be aware that both upward or downward trends require further investigation as they can be considered positive or negative.

No change	If the number of identified flaws remains consistent this indicates that the security posture of your application/s is being maintained.
Upward trend	Positive This can indicate improvements in your capability to identify flaws. This may include the increased: Effectiveness in flaw identification tools / techniques Scope of systems covered in your programme Negative This can indicate declining security standards.
Downward trend	Positive This can indicate improving security standards. Negative This can indicate a reduction in your capability to identify flaws. This may include the decreased: Effectiveness in flaw identification tools / techniques Scope of systems covered in your programme

Finding / Flaw Remediation Rate

Track the rate of flaw remediation over a set period. Flaws are remediated due to:

• The deployment of changes;
• Patching of vulnerabilities in utilised technologies;
• Maintenance of technologies or alignment to security best practice standards.

What to look out for

Be aware that both upward or downward trends require further investigation as they can be considered positive or negative.

You will need to ensure that flaws marked as remediated have been fixed. Incorrectly closing flaws distorts the remediation rate as well as the overall security posture of the application.

No change	If the number of remediated flaws remains consistent this indicates that the resourcing level is being maintained.
Upward trend	Positive This can indicate an increased level of effort / resourcing or more effective enforcement of security standards. Negative This can indicate the potential gamification of the vulnerability management process. Check to ensure that flaws are not being incorrectly closed or suppressed.
Downward trend	Positive This can indicate a reduction in the total number of outstanding flaws. Negative This can indicate a decreased level of effort / resourcing or a decline in enforcement / adherence to security standards.

Flaw Growth Rate

The growth rate is derived from the flaw creation and remediation metrics. This is calculated by:

Flaw Growth Rate = Flaw Creation Rate - Flaw Remediation Rate

What to look out for

Upward and downward trends have a clear positive and negative correlation. From a security risk perspective, you want to see either no change or a downward trend to ensure that the associated level of risk is at least being maintained.

No change	A flat growth rate indicates that the security posture is being maintained at a consistent level. This may be an issue if you have a significant backlog of flaws.
Upward trend	Negative This indicates that the number of open flaws is increasing. An upwards trend can be a good indicator of increasing risk exposure.
Downward trend	Positive This indicates that the number of open flaws is decreasing. A downwards trend can be a good indicator of decreasing risk exposure.

Visualising the data

The following charts help to demonstrate how you can visual this reporting to support with the analysis of your data. The charts have been created based on the below table.

Flaw Creation & Remediation Rates

The below bar chart summarises the flaws identified and remediated over a period of six months.

If you were seeing this within your own data, you would want to determine why there is such a disparity between the rate of flaw creation and remediation. This is highlighting a concerning upwards trend.

Flaw Growth Rate

The below waterfall chart demonstrates the flaw growth rate over a period of 6 months. This clearly identifies a growth trend and shows that the total number of flaws have grown by 46 over that period.

Whilst the chart demonstrates a lagging (historic) indicator this can also be used as a leading (future) indicator in projecting trends. Given the identified average monthly growth rate of 8 flaws, you can predict that based on the current trajectory the backlog of flaws will end up doubling to 92 within the next 6 months. This provides a clear indication of increasing risk exposure.

What actions should you consider taking?

On the basis that the reported data is correct there are a couple of actions that you will want to take.

Reduce newly created flaws

Its always easier and more cost effective to address the flaws early in the software development lifecycle. You will want to consider:

• Defining and enforcing a secure coding standard;
• Integrating security tools (i.e. SAST, DAST) into the development lifecycle;
• Improving the security capability of your developers / testers
• Improving the security team engagement into the development workflow.

These actions will help to reduce the number of identified flaws within new deployments.

Remediate the flaw backlog

The flaw growth rate has led to 46 flaws in the production environment. The existing remediation priority / resourcing is insufficient to maintain the flaw backlog let alone reduce it. Investigate what can be done to increase the rate of remediation.

Correlating the flaw growth rate with the underlying risk will help you to indicate where the level of risk is outside of your company’s appetite. In doing so this may help you in getting increased resource allocation to address the flaws.

Delivering a behaviour focussed security training programme

Companies often start out delivering a security training program to meet compliance requirements driven by standards and regulation. This helps to tick the compliance check box but is unlikely to deliver the security goals and objectives your organisation requires to protect its information.

A significant proportion of those who work in information security are often keen to focus resources on delivering technical solutions. Technology alone cannot solve the security challenge and needs to be balanced along with consideration of people and process. An effective behaviour driven training and awareness program can transform your staff from a perceived security weakness to a key security strength.

This article considers what you need to deliver an effective behaviour driven programme.

Identify different target groups and training topics / needs

The threats and vulnerabilities associated with individuals and job roles will vary. Consider how vulnerable, attacked and privileged the staff are in your organisation. Use this information to target content to achieve the greatest impact (i.e. reduction of security risk). The following provides an explanation of these risk factors.

Vulnerability

Has an individual proven vulnerable to specific threats in the past such as installing malware or clicking phishing emails? If they have historically been vulnerable to a threat, without a change in behaviour (intervention) they have a higher probability of being susceptible to comparable threats in the future.

Attacked

Is an individual being actively targeted? This provides an opportunity to see which individuals or groups are being targeted and the types of attack they are experiencing. Targeting training to specifically address identified threats will deliver a far great impact than providing generic / non-specific content.

Privileged

Consider the level of privilege an individual or target group have? By privilege I mean the authority possessed by a particular individual or group. In information security this relates to the level of access they have to systems or information (read, modify, and delete). Those with a higher level of privilege are more likely to be targeted by attackers as they impact of compromising them is often far greater. The below are an example of roles that would be considered to have a higher level of privilege:

• Finance – ability to make / approve payments
• Directors – access to highly confidential intellectual property
• IT – administrative access to systems

Consider these three factors in determining the risk related to individuals or groups. You are going to need to prioritise targeting and tailored content towards those that are highly vulnerable (increased likelihood), have significant privilege (increased impact) and are being actively targeted (increased likelihood).

Whilst you have little control over whether an individual is being attacked you can reduce the likelihood and impact of compromise by increasing their capability through training / awareness and managing privilege through adherence to the least privilege principle.

Continual reinforcement of training

By delivering targeted training frequently you can increase the likelihood of improving your staff capability at identifying and responding to threats. Continual reinforcement helps to address the following challenges.

New and changing threats

The threats your organisation faces will evolve over time. Your program needs to be responsive to address new and changing threats as they happen. Failure to adapt will reduce the overall effectiveness of the training you deliver.

Forgetting curve

Hermann Ebbinghaus (a 19th century German psychologist) introduced the concept of a forgetting curve. He identified that people forget 90% of what they have learned within a few hours after learning it. This is down to the information remaining in short term memory. Continual reinforcement of training has been proven to increase the likelihood that information learnt will persist within long term memory.

Deliver positive security behaviour change

Behaviour is the “way in which one acts or conducts oneself”. If an individual has historically demonstrated bad security behaviours, they have an increased probability of repeating those behaviours. Throughout your organisation staff will demonstrate both positive and negative security behaviours. You will need to design and deliver interventions to deliver a change to those behaviours.

Getting Started

It can be daunting to know where to start. I would suggest using the Cybsafe Security Behaviour database to get started. This provides a comprehensive cyber security behaviour database that is maintained by a global community of security professionals and academics. In time you will want to supplement this list with behaviours that are unique to your organisation.

Delivering change of behaviour

To change behaviour you will need to look into designing and implementing interventions to support in the delivery of change. Interventions are specifically designed to address factors such as capability, opportunity and motivation that are currently impacting delivery of the desired behaviours by individuals in your organisation.

Analysing behaviours and designing interventions are a significant topic that I will address within a follow up article.

Resources

If you want to understand more around changing behaviours, there are some great resources available. There is a practical guide available covering the Behaviour Change Wheel. This will help you to analyse / define behaviours and design / deliver interventions.

The Information Security Forum (ISF) have produced a number of whitepapers covering Human Centred security. These are well worth a read and are specifically targeted at Information Security. They provide detail related to initiatives that can help deliver effective security interventions.

Summary

I often hear a level of frustration from those working in Security Education, Awareness and Training (SETA) due to being afforded limited resources to operate their programs. By shifting the focus to delivering security behaviours you will be able to demonstrate the value that your program is delivering and in doing so can produce a stronger business case for greater levels of investment.

Human-centred security is a hot topic in the information security world. Its great to see those in security learning from other professions such as psychology in order to increase the effectiveness of their own initiatives.

By building out measures to track behaviours you will also be creating an invaluable data set that will not only help you identify past behaviours but will also support in the prediction of future behaviours.

The fundamentals of Information Security

Information Security is a specialised risk management function that supports the business to understand and manage security related risk. As a team they provide advice and help to design, implement and operate security controls to bring security risk into the businesses risk appetite or at least within risk tolerance. I will explore this statement throughout this article as it can be confusing to understand what this actually means.

The Information Security team often consists of differing specialisms to enable security management across diverse subject areas. The function is often perceived to be technical in providing IT/Cyber Security. Information Security is wider in scope and seeks to equally manage security risk relating to people and process in addition to technology. Through effective security risk management the team seek to enable (rather than block) the organisation to take advantage of opportunities. This is achieved through balancing risk and reward.

In NIST SP 800-59 Information Security is described as:

“The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.”

The goal is to protect information and information systems to provide the three key components that make up the CIA triad. These are:

• Confidentiality
• Integrity
• Availability

Confidentiality

Access to information should be restricted to only those who need access to it. This protects information to ensure it is only accessable to those who have a need to know it as part of their role.

Consider the scenario

A long standing member of staff has worked across multiple departments / functions within the organisation. Their level of access has increased to allow for their new role but previous access has been retained. They have access to more information than they require and as a result pose a far greater risk to the organisation through both the malicious or accidental exposure of data.

Integrity

Assurance that information is accurate, and reliable. This protects against unauthorised modification of both data at rest (in storage) or in transit (in transport).

Consider the scenario

A member of the customer service team are involved in making payments to customers. A lack of adequate controls around making changes to customer bank details increases the risk of internal fraud on the customers account.

Availability

Information is available to authorised staff as and when they need it. This protects against destruction or loss of data and disruption to services.

Consider the scenario

The organisations systems are subject to an external Denial of Service attack. A lack of adequate controls leads to the systems being unavailable to customers at their point of need.

To help understand the initial statement its important to understand the fundamentals of risk and how it applies in the management of security risk.

Risk Management

Risk itself is defined by ISO as:

"The combination of the probability (likelihood) of an event and its consequence (impact)."

The definition of risk used within Information Security is often bias towards negative consequence. Risk management requires a more balanced view between security risk (CIA impact) and opportunity risk as risk itself can also be positive.

The fundamentals of risk management require an organisation to define its risk appetite. This is the amount of risk that an organisation is willing to accept. Risk is a balance between the positive opportunity (what could we gain) and the negative consequence (what could we lose). The level of appetite is determined using a risk matrix that is typically based on likelihood (expected frequency of event) and impact (often determined through categories such as finance, reputation, regulation). Appetite states that this is the level of risk we as an organisation are willing to operate at.

The level of acceptable appetite will vary considerably between organisations with those in heavily regulated areas often more adverse to taking risk. An organisation may set out that it has a low appetite for risk but there will be situations where it is willing to take higher levels of risk (tolerance) as this is justified by the potential reward. This risk tolerance is the level of variation management are willing to accept.

There is a limit to the level of risk tolerance that an organisation can take which is the risk capacity. This is the level of risk that can be tolerated without potentially compromising the existence of the organisation.

Managing Information Security Risk

The Information Security team perform risk assessments and provide advice / consultancy on how to effectively manage risk. The team articulate the security risk and advise on how it can be mitigated. This information supports management in making an informed decision balancing risk and reward in pursuit of the organisation’s goals. Where the level of risk being taken is above appetite an escalation process needs to be followed to ensure the risk is owned and effectively managed. The stakeholders involved in the escalation process should be expected to increase in seniority as the level of risk being taken increases.

For risk to be effectively managed it needs to be documented to ensure the organisations overall risk posture is understood. Failure to identify or acknowledge risk or its blind acceptance undermine efforts to manage risk and can lead to an organisation taking unjustified risks or even exceeding its capacity for risk.

Security risk needs to be considered in terms of both existing risk (current status) and emerging risk (future status). There will always but short to medium term challenges but its important to balance these out with longer term strategic planning to enable organisations to adopt new innovations securely and within appetite / tolerance.

Security Controls

Security controls are implemented to be able to bring security risk to a level acceptable by the organisation. Risk management does not require controls to be effective, it simply requires controls to manage risk sufficiently within an acceptable threshold.

The controls themselves need to be in proportion to the risk. Where the cost associated with the realised risk is less that the cost associated with implementing and operating the control this cost cannot be justified. A role in information security requires a level of pragmatism to design and implement controls that are proportionate to risk whilst allowing organisations to take advantage of new opportunities.

Lawrence Gordon and Martin Loeb are economists at the University of Maryland. They published a study on “The Economics of Information Security Investment” in 2002. In this they suggest that the optimal amount to spend on information security should never exceed 37% of the expected loss resulting from a security breach. As with anything in risk this is subjective but provides a potential guide as to what level of spend is considered proportionate in the management of security risk.

Security Resources

Information Security resources are often limited in both staff numbers and budget. This makes it important to understand where the greatest levels of security risk exist so that resources can be appropriately prioritised. This can be achieved through assessing the value of assets to identify their risk to the organisation. For each asset this process often involves associating a risk rating against each component of the CIA triad. This approach seeks to proportionately apply resources according to risk rather than attempting to protect all assets equally.

Hopefully this post has helped build your understanding of the fundamentals of Information Security as well as appreciate the wider dependency on risk management within the organisation.

Keeping track of your applications' security posture

There are so many different indicators that you can use to track the security posture of your applications. The challenge is to determine what to track and what good looks like. Make sure that the indicators that you track offer value and aren’t just creating noise. You’ll also need to differentiate between increased risk and improved effectiveness of security controls.

The intention is to comprehensively implement controls and ensure they are efficient and effective at meeting the desired outcome. Do your indicators help you do this?

In this article I’ll be discussing application security indicators and some wider considerations around how to use them to monitor the ongoing effectiveness of your security initiatives and programs.

General Considerations

Some basic considerations:

• Check which CVSS version they utilise, where possible use a consistent version;
• Check comparable findings across tools to ensure vulnerabilities have consistent severity ratings;
• Question the validity of the findings, not all findings will be valid;
• Tools require refinement to reduce false positive and false negative results;
• Watch out for exceptions being creating around false results, check that these are and remain valid.

Quality of findings

Its important to note that the quality of findings will vary across controls. Penetration testing will involve an individual proving the existence of a vulnerability. Automated tools especially those that are unauthenticated have a higher probability of identifying false results.

Of the total findings identified check how many are:

• True positive;
• False positive – incorrectly identify a vulnerability;
• False negative – incorrectly identify that a vulnerability does not exist.

You’ll need to go through a process of refinement to reduce the number of false findings. This may involve recording respective false findings as exceptions within your tools.

Potential Indicators

There are lots of potential indicators that you can track. The following are some indicators for you to consider. These are all impacted by the quality of findings and the consistency of ratings. Refine the tools used to reduce any false results and ensure consistent severity rating of findings.

Control Implementation Indicators

According to NIST 800-55 implementation measures demonstrate “progress in implementing programs, specific security controls, and associated policies and procedures.”

Number of automated tests and tools

Determine what proportion of your applications are in scope for your security services. From that scope check how many are covered by your services. It doesn’t matter how effective your controls are if the scope of implementation is limited.

Assessment Coverage

Check what proportion of the application is covered by the assessment. Seek to maximise the coverage of your controls.

Assessment Frequency

Check how frequently security assessments are being performed against the in scope applications. Does this frequency adhere to your or industry defined standards?

There is a balance to be found according to your organisations risk profile and the resources available to you. Testing:

• Infrequently will leave vulnerabilities undetected on your applications for longer durations;
• Frequently will provide you with a more frequent snapshot of your security posture but is more resource intensive to operate.

 

Control Effectiveness / Efficiency indicators

According to NIST 800-55 Effectiveness / Efficiency measures “monitor if program-level processes and system level security controls are implemented correctly, operating as intended, and meeting the desired outcome”. The following are some potential indicators to consider.

Number of application vulnerabilities

At a very basic level you can track the number of vulnerabilities across one or more applications. The number is typically tracked along with the respective severity ratings:

• Critical;
• High;
• Medium;
• Low.

Ratings are reflective of the vulnerabilities exploitability and impact. The vulnerability score is typically derived using the Common Vulnerability Scoring System (CVSS). It is important to note than a combination of vulnerabilities can represent a higher severity to the application than the individual ratings considered in isolation. For instance two medium findings combined may constitute a critical vulnerability.

Type of vulnerability

Tracking the type of vulnerability helps to apply context to the vulnerabilities identified across applications. Example types include:

• Cross Site Scripting (XSS);
• SQL Injection;
• Cross Site Request Forgery (CRSF);
• Insecure Cryptographic Storage.

For a more comprehensive list of web application vulnerabilities see the OWASP Top 10.

Look out for consistent / repeat findings across one or more applications. These can be an indicator of weak standards or poor implementation of standard requirements. Seek to understand the root cause rather than trying to address findings on a case by case basis.

Source of discovery

It is common to have multiple controls that are used to identify application vulnerabilities. Consider correlating the number, type and quality of findings with the source tool. This helps to determine which tools and processes are most effective and offer the greatest return on investment (ROI).

Average Time to Fix or Defect Remediation Window (DRW)

From the initial identification of a vulnerability track how long it takes in days until it is verified closed. Companies will typically define time to fix requirements in accordance with the finding severity rating.

Make sure you:

• Refer to the original identified date as findings often come from multiple sources;
• Verify that findings have been closed.

This indicator will help determine if vulnerabilities are being addressed within the timescales set out in your standards. Repeated failure to meet the agreed timescales can be a good indicator of increased risk exposure.

Finding / Flaw Creation Rate

Track the rate of new findings over a set period. Its worth noting that an increase in findings may relate to an improvement in your ability to identify findings rather than a drop in development standards.

Finding / Flaw Remediation Rate

Track the rate of remediated findings over a set period. Make sure you verify that findings are closed. It’s possible that an applied fix isn’t sufficient to address the finding.

Finding / Flaw Growth Rate

If the finding creation rate exceeds the finding remediation rate this is a key indicator that vulnerabilities are increasing. This is a good way to identify increasing risk exposure.

Flaw Growth Rate = Flaw Creation Rate – Flaw Remediation Rate

Factor in the severity rating of findings. An increased growth rate driven by low findings alone may not suggest an increased risk exposure.

Density

Not all applications are created equal. Larger applications have a greater attack surface that can be exploited and its reasonable to expect them to contain a greater number of findings.

Consider tracking the number and severity of findings according to a defined density such as lines of code, number of pages or screens. This will be a more effective indicator of the security standard of an application.

Rate of findings per lines of code = Lines of Code / Number of Findings

It may be difficult to source sizing details for applications. Investigate what tools are available to you to support gathering of meta data relating to your applications.

Weighted Risk Trend (WRT)

It is difficult to articulate the actual risk of applications based on just the volume and severity of their findings. WRT makes it possible to derive a single measure which uses the business criticality of the application to determine risk in the context of the business.

WRT = ((critical multiplier x critical defects) + (high multiplier x high defects) + (medium multiplier x medium defects) + (low multiplier x low defects)) x Business Criticality

Choose severity multipliers that work within your organisation and make sure the calculations you use are transparent to the intended audience. Multipliers could be assigned scores on a simple basis of a range of 1 (low) to 4 (critical) or with wider weighting increasingly afforded to the more significant severities such as:

• Critical = 9;
• High = 6;
• Medium = 3;
• Low = 1.

Rate of Defect Recurrence

Identify the reoccurrence of previously remediated findings. Look out for:

• Version control related issues that lead to loss of security fixes in the production environment;
• Remediation of issues without solving the root cause of the problem;
• Developers that lack security awareness may continue to produce insecure code overwriting that which was previously secure.

Consider Business Context

Security findings need to be considered in the context of the wider organisation. For instance, an application handling confidential / regulated data will pose a greater risk to the company than a brochureware site containing publicly accessible data. Look to prioritise your resources to effectively manage the security risk of your applications.

Application criticality

Determine the criticality of your applications to the organisation. This is often used to determine / prioritise the scope of security services offered. Typical factors often include:

• Type and volume of data;
• External availability;
• Compliance or contractual requirements.

Business Impact Assessments (BIA) are a useful source of information.

Gamify reporting

In isolation it can be hard to articulate what a good application security posture is. Organisations typically own / operate multiple applications. Within a large organisation its viable to expect this to be in the hundreds or potentially thousands.

Consider the comparison across regions / business lines / legal entities / departments / functions within your organisation. Identify those with the best and worst security posture and encourage some friendly competition. You could even create a league table so that the different areas can easily see how they compare to each other.

A mean of the overall rating will enable you to trend indicators over time and track increasing / decreasing trends in your organisations overall security posture.

Summary

Identify a select number of key application indicators that will support you track the effectiveness of your controls. Be careful to avoid tracking data that does not provide an indicator of implementation, effectiveness or return on investment (ROI). Avoid tracking data that provides no clear indication as this can create noise and detract from those indicators that are important.

Target indicators to respective audiences to ensure that stakeholders have access to the right information. Identify where indicators are increasing / decreasing and determine what actions are required to address any increasing risk exposures.

Its important to work with stakeholders involved in the delivery / operation of your security controls. Work closely with your development / technical teams to educate them in the usage of the tools and provide guidance around remediation. Make sure that you recognise stakeholders for improvements that are being made and support them in their on going journey to improve.

Let me know what application indicators you track and what you have found to work effectively within your organisation.

Preparing for your Cyber Security journey

Current State

Teams in security often struggle with tracking the effectiveness of the programs / services / controls that they operate. It is quite common to see measures, metrics and indicators that have no correlation with company / department goals and objectives. This lack of understanding typically leads to:

• A large amount of measures / metrics that simple generate noise;
• A lack of clear action / outcome required in response to findings;
• Ineffective application of resources to monitor and produce reporting;
• A lack of quantifiable evidence showing the Return on Investment (ROI) of programs and initiatives.

This article is intended to provide you with a foundation of how you can track progress towards or achievement of your goals. The principles discussed here are not security specific but will provide a useful grounding for follow up articles that will specifically focus on tracking performance across different security domains.

The first place to start is through understanding the goal/s of your company. For security goals to be effective they need to align with the wider business goals and risk appetite. This will help to ensure you are progressing in the intended direction of travel.

Goals

Identify your goals

These are an observable and measurable result (desired state) requiring one or more objectives to be achieved often within a defined timeframe.

A goal tends to be long on direction, and short on specific tactics. A goal is the following:

• Defines the destination;
• Changes the direction to move toward the destination;
• Changes the mindset to adjust to and support the new direction;
• Creates the necessity to develop specific tactics.

Change is constant. Expect your goals to change with time and be prepared to add, update or remove corresponding objectives.

Set objectives (action plans) to achieve your goals

Objectives set a specific result that a person or system aims to achieve within a timeframe and given available resources. Objectives are about tactics. Tactics are action plans to get from where you are to where you want to be. 

A goal defines direction to the destination, but the road to get there is accomplished through a series of objectives.

Determine the risks to achieving your objectives

Risk is the effect of uncertainty on objectives. Identify what risks exist that could stop you from achieving your objectives. For any risks that are outside of the company risk appetite identify suitable risk response actions and incorporate required actions into your objective action plans.

Evaluate the relevance of your goals using S.M.A.R.T.E.R goal setting

There are 7 steps you need to follow to ensure your goals remain effective.

1. Is your goal Specific?
2. Can you Measure progress towards that goal?
3. Is the goal realistically Attainable?
4. How Relevant is the goal to your organisation?
5. What is the Timeframe for achieving this goal?
6. Evaluate your goal and determine its relevance to your business?
7. Revisit your goals to assess the outcome (success or fail).

Be clear about what it is you are trying to achieve and set realistic time-frames to work towards. Avoid setting goals that you are unlikely to be able to achieve. This is a particular issue where you have a dependency on others who are outside of your circle of influence.

Examples

Goals	Achieve a secure build standard for infrastructure and system assets	Achieve secure infrastructure and system assets
Objectives	Define baseline security build standards; Configure assets to adhere defined standards; Identify and remediate deviations to standards.	Apply security patches; Identify and remediate vulnerabilities.
Risks	An external attack leads to unavailability of infrastructure / systems.	An external attack compromises the integrity of company data.

Desired State

Goals set the destination and direction of travel to transform your program from its current state to a desired state. Objectives are the action plans that determine how your goals are going to be achieved.

Use of S.M.A.R.T or S.M.A.R.T.E.R goal setting supports the identification and maintenance of relevant goals. Its important to reevaluate your goals and objectives to ensure they remain relevant in progressing towards the desired state..

Your journey towards secure development

This article focuses on understanding web security risks and building the foundations for secure development. This is a large subject area that I will look to address across a number of articles.

It’s important to integrate secure practices into your software development lifecycle. Even with a strong defence in depth approach to security, poor coding practices will leave you susceptible to compromise. Hardened server builds and Web Application Firewalls (WAF) won’t provide complete protection if your applications are insecure. These should be seen as a supplement to and not replacement for secure coding.

There are numerous vulnerabilities that a WAF isn't going to protect you against such as:

• Script injection (i.e. Magecart type attacks);
• Concurrency (multiple concurrent user session) flaws;
• Business logic flaws.

As we become increasingly reliant on software in our every day lives the importance of maintaining the confidentiality of our data as well as the integrity of transactions is of paramount importance.

Understand security risks to applications

For web applications the OWASP top 10 is a great place to build your understanding of the most critical security risks to web applications. As at the time of writing this article we’re on the 2017 version. This list is maintained by OWASP to ensure it remains reflective of the latest security risks. Even with these updates there are common flaws that are repeated across the versions. Despite being widely documented with proven mitigations the likes of SQL injection and Cross-Site Scripting (XSS) flaws remain prevalent across today's web applications. OWASP is a great resource to not only understand the risks but to also understand how to code securely and perform effective security testing.

There are a wealth of readily available resources. The CWE/SANS TOP 25 Most Dangerous Software Errors is another useful resource to refer to.

If you lack formal company security standards a decent place to start is to require mitigation of the OWASP Top 10 or CWE / SANS Top 25 vulnerabilities within both your internal teams or third parties via Service Level Agreements (SLAs).

A word of note from experience. Just because your company is outsourcing to a experienced software development company don’t assume that good secure coding practices will be followed. Expect to be delivered a minimum viable product (MVP) as companies look to reduce costs and maximise profits. Make sure your security standards are included in that minimum. Trying to include these in retrospect after an initial contract is agreed is often far from straightforward. Typical challenges may include:

• Renegotiating a new contract / service agreement - in large organisations this can be particularly onerous. I've been involved in these situations that take in excess of 6 months to resolve;
• The individual who is accountable for the third party may have limited motivation to instigate or oversee delivery of the changes;
• It can be costly even if your company has negotiated decent rates for services, changes to those services often come at a premium.

Secure Software Development Framework (SSDF)

Having spent a considerable period of time working in development I’ve seen and been involved in development practices of wide variations in maturity. Take my word for it that poor development / change management practices are not just limited to small businesses!

It doesn’t matter what your current level of maturity is. The key is to understand your current state and desired state. You’ll then want to define a program to enable transformation (through delivery of milestones) to your desired state.

A good place to start is with reviewing your existing processes against the Capability Maturity Model Integration (CMMI). You need to understand what you have and its current state of maturity before you can look to make improvements.

There are a wealth of resources available providing detail on what your desired state might look like. The OWASP Software Assurance Maturity Model (SAMM) supports the complete software development lifecycle and covers key categories. For each category there are 3 maturity levels provided helping you get started and understand a path of progression. This is comprehensive covering categories from Threat Assessment through to Education and Guidance.

There are various alternatives to consider such as:

• Building Security in Maturity Model (BSIMM);
• Microsoft, Security Development Lifecycle;
• CMMI Development.

A framework helps to identify the categories you should consider and enables you to take a structured approach to modelling what you have and determining where you want to be. These frameworks will need to be tailored to your organisations. There is no mandate that you need to achieve the highest maturity ratings across all the categories. You’ll need to consider what fits within the appetite of your organisation to understand what levels of maturity will meet your needs.

NIST have released an interesting paper covering how to mitigate risk of software vulnerabilities by adopting a SSDF. This is a comprehensive resource about this topic and well worth a read.

Final Thought

When developing secure development practices it is vital to understand the type of vulnerabilities you’ll need to address. Good coding standards combined with vulnerability mitigation's (bespoke or part of a framework) will make substantial improvements to the security posture of your applications.

As the security maturity of your development practices improve you’ll see a drop in the number of vulnerabilities being identified in your production systems through automated vulnerability scanning and penetration testing. This will reduce the potential risk of compromise to your applications and lower the cost of remediation as they are addressed earlier in the lifecycle.

Be proactive in your approach and not reactive:

• Proactive - avoid vulnerabilities or fix early in the lifecycle;
• Reactive - playing whack a mole with a multitude of vulnerabilities in production. Being in a constant cycle of dealing with the issues rather than seeking to address the root cause of the problem.

It doesn’t matter where you are on your own security journey, every company is at a varying level of maturity. You just need to understand where you currently are and where you are trying to get to. There is no better time than the present to get started!

I’ll be looking to create a series of security in development related articles to cover some other important topics. It would be great to get your thoughts on the topics covered along with any experiences that you’ve had that can be of help to others.

Cyber Security on a small budget

It’s often felt that large companies have a distinct advantage over smaller ones as they have significantly larger budgets to help invest in people, process and technology. Smaller companies often lack the level of investment but have some distinct advantages over their larger counter parts. To name just a few, they:

• Lack the organisational complexity – it’s often easier to make a decision and implement change;
• Don’t have the large and sprawling technical infrastructure;
• Aren’t having to contend with a multitude of legacy infrastructure and systems;
• Are able to embrace new trends and adapt more quickly.

For Cyber Security to be effective in any organisation you need support and buy in from the top. A lack of senior level backing will undermine what you’re trying to achieve within any size of organisation.

Given a limited budget and a lack of expertise where can you start within a small organisation and is it possible to level the playing field?

Building the foundations

I’ve often seen a rush to invest in technology to solve the security challenge. The root of this is likely attributed to many people within the industry having a background in technology (myself included). I’d start out building out an Information Security Management System (ISMS). This is the foundation by which your wider services will be developed.

Information Security Management System (ISMS)

There are various frameworks and standards of best practice readily available. Consider adopting the likes of ISO27001 or the NIST Cyber Framework. It’s also worth considering if there is or will be a future certification requirement.

There are some key actions that you need to take:

• Understand what already exists – can you utilise an existing foundation or do you need to start from scratch;
• Develop a risk management capability or integrate into an existing one – ensure it is fit for purpose;
• Understand the risk appetite of the organisation – check that the stated appetite reflects the culture of the organisation;
• Determine and prioritise what you are trying to protect – don’t try to secure everything equally;
• Identify compliance and regulatory requirements;
• Given the resources available, set out a strategy that will enable you to bring risk within appetite;
• Develop action plans that will support the successful delivery of your strategy.

Involve others in the journey and make sure that you manage expectations. It’s widely recognised that incidents will happen, avoid offering something that you can’t deliver on. There’s an interesting article on zdnet that I suggest reading showing the average tenure of a CISO is just 26 months due to high stress and burnout. Not managing expectations from the outset won’t help!

Setting out your security programs

Follow the action plans you’ve set out in order to achieve your defined strategy. Consider adopting best practice standards. There are a multitude of useful resources readily available that you can look to adopt depending on the existing maturity of the organisation. The following are potential resources you may consider using:

• Cyber Essentials;
• CIS Controls List;
• ISO 27002;
• NIST 800-53;
• UK 10 steps to cyber security.

This is not intended to be an exhaustive list. If you’ve got any resources that you rate, then let me know. As you go through the list of controls you’ll notice many can be delivered without the need for a significant capital outlay. With the continued adoption of cloud-based services smaller companies are becoming increasingly able to achieve higher standards of security through utilisation of services such as Software as a Service (SaaS).

If you’re starting from a very low baseline look to build out some of the basic controls first. Consider the likes of Cyber Essentials or choosing a standard such as the CIS Controls and starting out with implementation of the basic controls first.

Starting from scratch

It can feel daunting to be setting up an ISMS or equivalent when nothing or only a very basic foundation exists. It’s always worth considering if there are off the shelf solutions readily available that can be purchased and adapted to your needs. For instance:

• ISO toolkit / ISO27001 compliant policies are available;
• Security as a Service (SECaaS).

It's far easier to acquire existing resources and adapt them to your requirement than to start from the ground up. Consider when the resources you produce (such as policies / standards) are good enough rather than waiting for them to be perfect. These documents will evolve and mature along with the security capability within your organisation.

When starting out remember it takes time to implement and build out a security program. Your focus should be on continuous improvement rather than quick fix. Over time you will have the opportunity to incrementally raise the minimum-security standards across your organisation.

Resources

It’s been widely recognised that there are a shortage of people in the Cyber security field. The gap between companies hiring needs and available candidates is expected to continue growing. This combined with the high average salaries makes recruiting and retaining a suitable candidate particularly challenging.

Every organisation needs to have someone ultimately accountable for security in the organisation. Within small businesses individuals will often be balancing a number of different job functions. If you lack the budget to recruit a full-time resource consider supplementing what resource you do have through outsourcing to professional service providers. Security providers are increasingly offering a Virtual CISO as a service to companies that need security support but on a part time or adhoc basis.

Final Thought

The needs of every organisation are different and will vary according to various factors (internal & external) such as the expectation of customers and the compliance requirements in your respective jurisdictions and sectors. It’s possible to build out and run an effective security program in small to medium businesses on a budget. Focus on building the management system and equally consider people, process and technology.

You’ll need to manage the expectations of others as well as your own. Set realistic objectives and focus on incremental improvement / maturity over time.

It would be great to get your thoughts on the topics covered along with any experiences that you’ve had building out your own security program.

Setting up and managing supplier security assurance

Every organisation faces a significant challenge in the management of risk associated with their suppliers and partners.  No organisation exists in isolation and all sizes of organisations will be reliant on the support of third parties.

For the purposes of this post I’m focusing on Information Security assurance.  There are other considerations around areas such as finance and legal that aren’t covered.

Depending on the sectors you operate in, organisations often face compliance requirements to provide assurance.  The scale and complexity of managing this program can grow exponentially with the number of third parties involved.

Your key objectives will be to ensure that the third parties you work with adhere to your required standards and within your companies tolerance for risk (be that low or high).

Setting up a program

I’ve had the opportunity to work within organisations across the spectrum from small to large enterprises.  They all face a similar challenge.

A typical program includes the following components:

1. Risk assessment

Determine the level of risk associated with the third party.  This involves assessing the risk severity posed by the third party according to the service provided.

These normally consider aspects such as type of data involved, access to systems, applicable standards and regulations (compliance).

2. Security questionnaire

This is intended to ask questions related to standard controls that your company would expect.  With the increasing compliance demands the length and complexity of these can be substantial.

Consider having different versions depending on the nature of the relationship as well as the risk severity posed. Bear in mind these can be time consuming for both parties to complete and review.

There are standard options readily available that may suit your needs (i.e. Sig Lite).  Alternatively you may want these to be based on your own policies / standards. This is more likely to be a requirement when you are in a heavily regulated industry.

3. Questionnaire review

Following a review of the third party you’ll want to identify any compliance gaps between their current security posture and the minimum you require.  Any gaps need to be assessed and suitable recommendations / mitigations raised.  Based on these you will need to agree and track a security program with the third party.  Enforcement of such a program is most effective when it stipulated within a contract.

4. Program management

You need to maintain oversight of third-party security programs.  This will enable tracking of progress in addressing the agreed actions.  Actions should be within agreed time periods and suitable levels of escalation followed if the third party fails to deliver to the agreed time-frames and standard.

5. Contracts

Security standards need to be legally binding.  This can be effectively enforced by including security SLA and / or OLA clauses within the contract.

Third party management program

Relationships between parties will evolve over time to adapt to the needs of the organisation or as a result of changing external factors.  As a result, it’s necessary to perform ongoing risk assessments of the third party to ensure they maintain adherence to your required standards.

Some important aspects to consider:

• Use cases and therefore risk associated with an engagement will change over time;
• Security events / incidents may occur at the third party that require special attention;
• Third parties change – events such as a company takeover, executive or senior management change can change the direction and culture of an organisation;
• Policies / standards evolve to meet changing requirements, so should third party management;
• Companies may move into and out of compliance over time as standards / capabilities rise and fall;
• You’ll want assurance / evidence of any security certifications to ensure they are still relevant / valid;
• Automate aspects of the program – utilisation of tools / platforms can really improve the efficiency of the program;
• Provide reporting / oversight of the program to the senior stakeholders.

For most organisations it won’t be practical to perform comprehensive risk assessments of all third parties.  Through a risk-oriented approach make sure to cover at least the highest risk ones.

The gap in available information security staff has been widely publicised.  Despite this there are options open to every organisation to resource this type of program.  This typically involves a hybrid of both internal and outsourced staff and services. 

Important considerations

Accountability

It’s important to remember that Information Security are advising on the level of risk posed by a third party along with recommending actions that enable a reduction in the level of risk.  This covers whether the expected requirements are being met and are within the risk tolerance of the organisation. 

The accountability associated with the risk does not sit with Information Security.  If your business decides to progress with a third party that is above an accepted risk tolerance level, then ensure the appropriate level of accountability is taken.  This is typically managed through a risk acceptance process.

Certifications

You’ll want to consider how much weighting you allow for certifications.  This will likely vary according to a number of factors:

• Coverage – are your control requirements sufficiently well covered;
• Scope – are the services you’re using fully, partially or not covered;
• Trust - are they attested by a trusted party or self-assessed;
• Validity – is it in date and can this be affirmed by a register.

Be aware that just because a company has a professional certification it does not guarantee they are secure or even managing security effectively.  Be careful to not be over reliant on them.

Classification

Organisations will have a myriad of different types of third-party providers.  Consider classifying them as it may not be suitable to perform the same type / level of assessment against each.

There are a number of factors to consider such as:

• What is the type and volume of the data involved;
• Are the impacted services subject to compliance requirements;
• Will the third party need access to the corporate network;
• Do the company need to attend onsite facilities.

Lifecycle

It’s important to recognise that third party assurance is an ongoing process.  Risk associated with third parties’ changes over time as the service and threats evolve.

Management

The volume of third parties, questions / answers, evidence and assessments makes this an administration intensive exercise.

It’s also important to not underestimate how much work is involved in collaborating with stakeholders, following up with questions and requesting evidence.

A program can be managed in spreadsheets, but this often adds considerable overhead in terms of time, coordination and administration.  It may prove more cost effective to utilise a third-party management tool.  Within medium to large organisations your risk, legal or procurement functions may already have a suitable tool you can use.

On-boarding

Information Security are often only one of a number a teams / departments involved in the on-boarding process.  For the program to be effective ensure you integrate into your organisations on-boarding lifecycle.

It’s far easier to influence and help reduce risk before a contract has been signed than after!

Prioritisation

Take a risk-based approach to identify your highest priority third parties.  With limited resourcing make sure you focus on your highest risks first.

Reporting

There are some important aspects of the program that you need to report on:

• How many active third parties you have and at what level of classification / priority;
• How many third-party assessments have been completed;
• Your backlog of third-party assessments;
• A realistic projection of what will and won’t be covered given available resourcing;
• Identification of third parties (and reference to risk acceptances) that are outside of risk tolerance;
• Identify suitable KPIs / KRIs to help track the increasing / decreasing effectiveness and risk exposure.

This is your opportunity to communicate the level of risk associated with the third-party program as well as highlight limitations based on the afforded resourcing.

Resourcing

It’s best to take a risk-based approach to determine how you prioritise your resourcing.  Every organisation faces a scarcity of skilled people combined with a limited budget.

Be realistic about what you can achieve with the resources available to you.  Spreading your resources too thinly often leads to a reduction in their overall effectiveness. 

Due to the often-high level of administration involved consider what seniority of role you need to perform each task.  Consider providing the lower skilled tasks to more junior positions or potentially outsource to a third party.

Final thought

Third party programs vary in size and complexity depending on the needs of the organisation.  This highlights some key areas to consider and is based on my own experience of what does / doesn’t work.  Even a fairly light program will help you to manage your third-party risk more effectively.

It would be great to get your thoughts on the topics covered along with any experiences that you’ve had that can help others either setting up or managing their own program.

Security qualifications, are they worth it?

There are a vast number of third-party institutions that provide professional certifications.  The two I often see asked for on job specifications are CISM and CISSP from ISACA and ISC2 respectively.

Trends in security qualifications vary on a year by year basis but these two have been consistently in the top ten.  For those interested in a typical top ten list take a look at this article from Forbes.

This is a big industry with institution members having to commit considerable time, effort and finance to earn and maintain these qualifications.

The positives

There are some clear positives:

• Development - they require you study to pass them as well as maintain through ongoing professional development;
• Job hunting - they provide potential recruiters with assurance over your level of understanding / knowledge;
• Job applications - they increase your chances of reaching the initial shortlist.
• Earnings - they make it easier to move between roles and negotiate a higher salary. 

The not so positives

The positives need to be balanced with the not so positives:

• Membership cost - if you’ve got certifications it can get expensive to maintain;
• Continuing Professional Education (CPE) Credits - there is considerable overhead in maintaining your CPEs;
• US focus - many of the institutions charge fees in dollars making them subject to currency fluctuations;
• Exams - these are expensive, long and often difficult to pass.

Not a replacement for experience

Qualifications provide a level of assurance over your ability, but expertise relies on experience.  Senior positions typically require a combination of qualifications and experience.  In these positions’ companies expect candidates to hit the ground running.

For the more junior positions there is an expectation that candidates will require more support in mentoring and development to reach the required experience level.   At a junior level, qualifications can be a real differentiator when applying for positions.

Given the shortage of skilled people in the industry there is a wider recognition that new staff will require investment to develop.

Continuous development

The security landscape is changing at a rapid pace.  Even if you don’t go down the qualification route you need to have a desire to challenge yourself and develop.  There are plenty of resources that you can make use of including webinars, conferences, online study and local groups.  Many of these are available at no cost.

How many qualifications should you have?

This is a difficult question and one I have personally struggled with an answer for.  I’ve currently got four professional security qualifications and am working on my fifth.  From conversations with my peers the answer relates more to the role that you are in.  For an Information Security Manager / Officer career path having either CISM / CISSP or both can be a real positive.

I’m personally intending to achieve a further two qualifications in the next few years (CRISC & CISSP).  That will take me up to four qualifications I have to maintain memberships for.  Given how costly this can be it will be hard to justify the expenditure beyond that.

I’ve worked with a variety of different people within the industry.  The majority (but not all) have one or more qualifications. 

It’s worth noting that some people choose to let them lapse.  Perhaps in this instance they were an enabler whilst the individuals didn’t have the required experience and a cost thereafter.

Can you have too many qualifications? 

This is an interesting point and not something I’d thought much until recently.  After reviewing a  candidate CV I was surprised by the number of qualifications and active memberships they were maintaining.  The CV in question showed that the individual had around 3 years’ experience and was averaging three major qualifications per year.  So, early on in their career and they were already paying out for several memberships and 9 qualifications.

Roles in security can be highly demanding and trying to balance development, work and personal life can be a challenge.  Over the last few years I’ve been trying to achieve one qualification per year.  I’m not convinced there is sufficient benefit to the individual to pay the cost required to maintain so many memberships and qualifications.

Final thoughts

From personal experience my qualifications have opened up opportunities and helped me get onto the initial short list for positions.  This has at least given me the opportunity to impress future employers in person.  They are not a replacement for experience but can certainly become an enabler when accompanied with it.

Its important to note that not all qualifications are equal.  Have a look at the job specifications you’re most interested in and choose qualifications that are going to enable you to progress within them.  Consider the value they will give you to make sure you can justify the time, money and effort it will take to achieve and maintain them.

These are my personal views.  I’d be keen to hear your thoughts.