Information Security - management reporting

As with any department within a sizeable organisation you need to produce reporting to communicate information to the board and senior management. You need to be structured and intentional with the reporting you produce to ensure it is delivering the right outcomes for your department as well as the wider organisation.

Reporting is an important tool that is required in enabling the delivery of a successful Information Security programme. This article provides some guidance on how you can be more successful in the delivery of your own reporting.

Purpose of reporting

Management reports provide a means of communicating information upwards. When producing these reports make sure you are clear about the objectives you are working towards to achieve your goals and are tailoring to the needs of your audience.

Focus on risk / reward and the outcomes for your organisation. This helps aid the understanding of the intended audience and will prompt / enable decision making to stimulate action where it is required. Your audience are the decision makers in the organisation and can positively or negatively influence in the delivery of your programme.

Structure your report

The following sections detail the content that you should consider including within your reporting.

Executive summary

Executives / senior management will receive a multitude of reports / communications. They are typically time short and want to know quickly if there is anything they need to be concerned with. Make sure your summary highlights any increasing risk exposures especially where they require decision making / action from the reader. Be aware that this may be the only portion of your report that they read.

Overview of security controls

The Information Security team are delegated the responsibility for operating security controls to enable the management of business risk. Whilst the team operate the controls the accountability for the risk is with the risk owner who delegates out the operation of those controls.

In larger organisations security controls are likely operated on behalf of many risk owners who are accountable for their department or entity. From a regulators perspective the regulated entity is accountable for their risk even if they have outsourced controls to their parent organisation.

Risk ownership will be with the board or senior management who have sufficient influence in the organisation to be able to manage that risk effectively. This report provides you with an opportunity to inform the risk owners how their controls are performing (through measurement / trending) and provide them with sufficient information to take decisions and drive action where it is required.

What to include	Why should it be included?	Example/s
Control Scope (KCI)	Be clear about what is / isn’t included in the scope of your security controls. If the reader isn’t comfortable that the scope is sufficient this will help to justify increased investment. It doesn’t matter how effective your security controls are if they only cover 5% of the overall scope!	We provide annual security assurance for 30% of our high security suppliers / vendors.
Control Effectiveness (KCI)	New threats emerge and existing ones evolve. This changing threat landscape will require you to adapt or replace your controls to meet with the latest threats faced by your organisation. The quality of your existing controls may reduce over time. Failure to adequately resource them or invest in their development may lead to them not being fit for purpose. Call out where controls are no longer adequate for effective management of risk. The controls themselves may still be effective to address the original threat but less effective against new or changed threats.	Our email security tools block 70% of malicious traffic. This has reduced from 90% in the previous quarter. We are seeing a growing threat in malicious applications targeted at our organisation. There have been 5 instances in the last 3 months. We lack an effective control to mitigate this growing threat.
Control Performance (KPI)	Make sure you include details relating to where your KPIs are failing to meet the agreed minimum-security requirements. You will need to correlate changes in your KPIs with the actual risk to the business.	10% of critical vulnerabilities are not addressed within the standard defined timeline. 15% of staff click on phishing emails. 5% of staff fail to complete their security training.
Security Risk (KRI)	Security controls exist to enable organisations to manage business risk within a set risk appetite or at least within a defined risk tolerance. Failing to manage risk within the overall risk capacity has the potential to threaten the viability of the organisation. Your objective is to identify increasing risk exposures to enable effective management of the risk.	We have experienced a 10% increase in security incidents. There has been a 10% increase in data breaches. We have experienced a 15% increase in spear phishing attacks leading to a 5% increase in malware incidents.

Important to note

An effective control is one that enables management of risk within risk appetite or risk tolerance. This means a partially effective control can be seen as adequate where it is enabling the effective management of the risk even if this isn’t ideal from the perspective of the control operator.

Security events / incidents

Provide an explanation of significant security events and incidents. Incidents represent realised risks and can be a good indicator of new threats and risk trends. These can be internal or external to the organisation such as:

• Compromise of a supplier network
• Incident experienced at another organisation
• Vulnerabilities receiving significant media attention

Where its internal make sure to detail what happened and what has / is being done to manage the incident. Where its external detail the mitigations that exist within the organisation or highlight the need for control improvements to address this new threat.

An incident, even one experienced by a third party can be an opportune time to get the buy in you need to deliver your initiatives!

Security programme / initiatives

Provide an overview of progress towards your objectives or highlight where the team are supporting in the delivery of wider business objectives. This is an opportunity to offer assurance that the Information Security department is adding value and meeting the needs of the organisation.

Where you are experiencing challenges / problems call these out and highlight the actions you are taking as well as detailing the actions required by the reader.

Your programme needs to be forward looking (working towards a desired state) and not just focussed on fighting fires.

Recommended actions

This is an opportunity to detail the actions that are required to deal with incidents, respond to emerging threats, correct any decline in control effectiveness / performance and respond to increasing risk exposure.

The information you provide needs to aid the understanding of the intended audience. This needs to prompt / enable decision making to stimulate action where it is required.

Important factors to consider

These are some key factors that you need to consider when producing your reports:

• Understand your audience – whilst this may be targeted at the board consider which other stakeholders (such as your regulators) may have visibility of them
• Make sure you communicate to the right stakeholders
• Provide clear and concise content that is easy for the intended audience to understand
• Produce reporting at consistent / set intervals – this is typically produced monthly or quarterly
• Avoid noise / padding as this just detracts from what is important
• Report on information that is important to achieving your objectives / goals
• Supply the right information to enable required decision making
• Make sure to highlight and recommend required actions that will lead to the required outcomes

Internal benchmarking

Whilst is can be difficult to benchmark against external companies it is possible to do a direct comparison of security indicators across your internal departments or entities. Consider use of gamification within your reporting through the introduction of game elements such as use of points and leader boards / tables.

Gamifying the reporting makes it easy to do internal direct comparisons and provides a level of competition that can help to drive improvements to your overall security posture. Make sure the metrics / indicators you include support in the delivery of your objectives. Avoid focussing resourcing in the wrong areas.

Looking beyond your organisation

Where the information is available consider benchmarking against other companies. This can provide a good measure of the capability / maturity of the organisation’s security programme. Benchmarks can be sourced from:

• Security rating platforms
• Security health check assessments
• Security metrics sourced from your controls

I hope this article proves helpful in making your reporting more effective!

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.

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.