What is the true cost of a cyber attack?

July 10, 2024 Håkon Olsen2 Comments

All businesses depend on digital tools, making them all vulnerable to cyber attacks to a smaller or larger degree. We regularly read about cyber attacks in media, and figures for the cost of the average data breach are reported in various publications – and they are ranging from small and insignificant to billions. If you operate a 5-person UX design consultancy, an average cost based on Fortune 500 company incidents is obviously not very useful.

The true cost is the combination of impact across multiple categories. First, the immediate costs include lost current business and direct handling costs. Long-term costs include lost future business, liability costs, need for extra marketing to counteract market loss of trust, as well as follow-on technology and process improvement costs due to identified security gaps. The actual cost depends on the readiness to handle the event, including backup procedures and training to use them.

Let’s consider the UX consultancy Clickbait & Co, and help them think about the potential cost of cyber attacks with the aid of a BIA. The founder and CEO Maisie “Click” Maven had been listening to a podcast about cyber disruption while doing her 5am morning run along the river, and called the CTO into her office early in the morning. The CTO, Dr. Bartholomew Glitchwright, was a technical wizard who knew more about human-machine interaction that was good for himself. Maisie told him: “I am worried about cyber attacks. How much could it cost us, and what would be the worst-case things we need to plan for?”. Dr. Glitch, who usually had an answer to everything, said “I don’t know. But let’s find out, let’s do a BIA”.

Maisie’s run along the river, while meditative, is also causing new worries through the impact of podcasts

Dr. Glitch’s BIA approach

Dr. Glitch is always in favor of systematic approaches, and doing BIA’s was no exception. He liked to follow a 7-step process:

Identify the value creating business processes
Describe the business processes in flowcharts
For each flowchart, annotate with digital dependencies in terms of applications, data flows, users and suppliers
Create a “super-flow” connecting the business processes together to map out dependencies between them, from sales lead to customer cash flow. This can be done at the end too, but is important to assess cross-process impact of cyber events.
Consider digital events with business process impact:
- Confidentiality breaches: data leaks, data theft
- Integrity breaches: data manipulation
- Availability breaches: unavailability of digital tools, users, data
Assess the impact, starting with direct impact. For each digital event, assess business process impact in terms of downtime (day, week, month). Mark the most likely duration of disruption.
Evaluate the total cyber disruption cost (TCDC) including
- Immediate costs: lost current business, recovery costs
- Longer-term costs: lost future business, marketing spend increase, tech investment needs, legal fees

Dr. Glitch and Maisie got coffees and got to work. They decided to focus on the main processes of the UX firm:

Sales
Digital design
Invoicing and accounting

Sales

They created simple flow charts for the 3 processes, starting with sales. The sales in the firm was mostly done by the two of them. They had two main sources of business: requests for proposals from customers coming in to their e-mail inbox, and direct sales outreach by phone and e-mail. The outline of the process looks as follows:

Now they started annotating the flowchart with the digital dependencies.

They had identified several digital dependencies here:

Hubspot CRM: used for all CRM activity, lead capture, tracking deals, etc
Office 365: create sales decks, e-mail, vidoe meetings
uxscan.py: internally developed tool to identify poor practice on web pages, used for identifying prospects to contact, and also in their own QA work
Digisign: a digital signature service used to sign contracts before work is started

As for users, they identified their own personal user accounts. Dr. Glitch had set up SSO for Hubspot and Digisign, so there was only one personal account to care about. The Python script was run on their own laptops, no user required. There are a few integrations, between Office365 and Hubspot, and between WordPress and the Hubspot lead capture form (not using an API here, just a simple iframe embed).

Dr. Glitch had made a shortlist of events to consider in the cyber BIA:

Ransomware targeting Sharepoint/Office365
Hacking of user accounts, followed by data theft (Hubspot, O365)
Mainpulation of uxscan.py code
DDoS of Digisign, Hubspot, Office365
Hacking of user accounts, followed by issuing fake contracts or bids (signed with Digisign)
Data breach of personal data (Hubspot)

Then they together made an assessment of the impact of each event on the shortlist in a table. The average deal value for Clicbait & Co is NOK 400 000.

Digital asset	Worst-case impact	Immediate cost	Long-term cost	Total cost
O365	Data leak and encryption (ransomware)	1 week downtime: 1 lost deal. Assume as base case. 2 week downtime: 2 lost deals Recovery consultants: 200 hours x 2000 NOK/hr = 400 000.	Marketing campaign to reduce brand damage: NOK 150k Lost business: 5 deals = 2 MNOK Legal fees: none, assuming no GDPR liability Cyber improvements: 100 000.	Immediate (800k) + Long-term (150k + 2M + 100k) = 3 050 000 3MNOK
Hubspot	Theft of customer list, deal sizes, by competitor. Duration may be short or ongoing, but the disruptive effect can be long-term.	No immediate business impact.	Future lost business: 30% of bids in the first year, 20 deals x 400k = 8 MNOK. Possible GDPR fine: 500 kNOK.	8.5 MNOK
Digisign DDoS	Cannot sign digitally, resort to manual process	No immediate impact, reduced efficiency.	No long-term impact, reduced efficiency.	0 MNOK
WordPress website	Unavailability – no leads collected	Lost business, assume 1 lost customer for a week of downtime. Direct cost: up to 50k to reestablish website if a destructive attack.	Loss of trust, leading to 1 lost future deal.	850 kNOK

Business impact form cyber events disrupting the sales process

From this quick high-level assessment they decide that a few mitigating activities are in order for the sales process; they need to improve the security of the O365 environment. This will likely include buying a more expensive O365 license with more security features, and setting up a solid backup solution, so it will carry some cost.

For the Hubspot case the impact is high, but they are unsure of the security is good or not. They decide to do a risk assessment of the Hubspot case, to see if anything will need to change. Maisie also decides to do a weekly export of ongoing deals to make sure an event making Hubspot unavailable can’t stop them from bidding on jobs in the short term.

For the Digisign case, they agree that this is a “nice-to-have” in terms of availability. They discussed the case of an attacker creating fake offers from Clickbait & Co and sign it with Digisign, but agree that this is far-fetched and not worth worrying about.

The BIA is a very useful tool to decide where you need to dig more into risk assessments and continuity planning – that is the primary value, not the cost of the worst-case impact itself.
Dr. Glitch.

Some thoughts on BIA’s for information processing events

Looking at the business impact of cyber attacks on the sales process we see that we expect some events to cause long-term damage to the business, without upsetting the internal workings of the process (information theft, data leaks). This is different from what we would find in BIA’s focusing on other aspects than information processing, but it does not make handling the event less important.

For events that lead to immediate disruption of the process, we can use the traditional metrics such as recovery time objective (RTO) and recover point objective (RPO). The latter is the target for when the system should be back up an functioning again, and the latter is about how much data loss you accept: basically it dictates the maximum time of data lost that is acceptable in an event requiring recovery.

Summarizing the findings from Maisie’s and Dr. Glitch’s business impact assessment, we can create the following table:

Process	Events	Impact	Recovery targets	Immidiate action
Sales	Ransomware attack	Downtime and data leak. Cost 3 MNOK	RTO: 2 days RPO: 4 hours	GAP assessment of security practices for O365 and backup
Sales	Data theft from Hubspot by competitor	Long-time business loss, possible GDPR fine. Cost 8 MNOK.	No process disruption Mitigation requiring marketing and communication efforts, future improvements, possibly certification/audits.	Risk assessment

Dimensioning BIA events presented per process.

Finally, lets’ summarize the process. The purpose is for each process to find the dimensioning disruptive events, and decide what the next step should be. The next step could be one of the following:

Do nothing (if the expected impact is low)
Do improvements (if it is obviously a problem and clear improvements are known)
Perform a risk assessment (if the uncertainty about the events is too high to move to improvements directly)

This means, look at each process alone, identify impact of disruptive events, plan next steps. After this is done for all processes, review the impact of each process on each other, to see if disrupting one process will have impact on another. if this is the case, it should be given higher priority in continuity planing and risk management.

Remember to subscribe to get the next post in your inbox – and get a free supply-chain assessment spreadsheet too!

Vendor Security Management: how to decide if tech is safe (enough) to use

September 28, 2021September 28, 2021 Håkon Olsen2 Comments

tl;dr: Miessler is right. We need to focus on our own risk exposure, not vendor security questionnaires

If you want to make a cybersecurity expert shiver, utter the words “supply chain vulnerabilities”. Everything we do today, depends on a complex mixture of systems, companies, technologies and individuals. Any part of that chain of interconnected parts can be the dreaded weakest link. If hackers can find that weak link, the whole house of cards comes crumbling down. Managing cyber supply chain risk is challenging, to say the least.

Most companies that have implemented a vendor cybersecurity risk process, will make decisions based on a questionnaire sent to the vendor during selection. In addition, audit reports for recognized standards such as ISO 27001, or SOC2, may be shared by the company and used to assess the risk. Is this process effective at stopping cyberattacks through third parties? That is at least up for debate.

Daniel Miessler recently wrote a blog post titled It’s time for vendor security 2.0, where he argues that the current approach is not effective, and that we need to change the way we manage vendor risks. Considering how many cybersecurity questionnaires Equifax, British Airways and Codecov must have filled in before being breached, it is not hard to agree with @danielmiessler about this. What he argues in his blog is:

Cybersecurity reputation service (rating companies, etc) are mostly operating like the mob, and security questions are mostly security theater. None of this will save you from cyber armageddon.
Stay away from companies that seem extremely immature in terms of security
Assume the vendor is breached
Focus more on risk assessment under the assumption that the vendor is breached than questionable questionnaires. Build threat models and mitigation plans, make those risks visible.

Will Miessler’s security 2.0 improve things?

Let’s pick at the 4 numbered points above one by one.

Are rating companies mobsters?

There are many cybersecurity rating companies out there. They take measure of themselves to be the Moody’s or S&P’s of cybersecurity. The way they operate is they pull in “open source information about cybersecurity posture” of companies. They also say that they enrich this information with other data that only they have access to (that is, they buy data from marketing information brokers and perform data exchange with insurance companies). Then they correlate this information in more or less sound statistical ways (combined with a good dose of something called expert judgment – or guessing, as we can also call it) with known data breaches and create a security score. Then they claim that using companies with a bad score is dangerous, and with a good score is much better.

This is definitely not an exact science, but it does seem reasonable to assume that companies that show a lot of poor practice such as a lack of patching, botnet infected computers pinging out to sinkholes and so on, have worse security management than similar companies that do not have these indicators. Personally, I think a service like this can help sort the terrible ones from the reasonably OK ones.

Then, are they acting as mobsters? Are they telling you “we know about all these vulnerabilities, if you don’t pay us we will tell your customers?”. Not exactly. They are telling everyone willing to pay for access to their data these things, but they are not telling you about it, unless pay them. It is not exactly in line with accepted standards of “responsible disclosure”. At the same time, their findings are often quite basic and anyone bothering to look could find the same things (such as support for old ciphers on TLS or web servers leaking use of an old PHP version). Bottom line, I think their business model is acceptable and that the service can provide efficiency gains for a risk assessment process. I agree with Miessler that trusting this to be a linear scale of cyber goodness is naive at best, but I do think companies with a very poor security rating would be more risky to use than those with good ratings.

mobster planning his next security rating extortion of SaaS cybersecurity vendors — Some security vendors have a business model that resemble extortion rackets of a 1930’s mobster. But even mobsters can be useful at times.

Verdict – usefulness: rating services can provide a welcome substitute or addition for slower ways of assessing security posture. An added benefit is the ability to see how things develop over time. Small changes are likely to be of little significance, but a steady improvement of security rating over time is a good sign. These services can be quite costly, so it is worth thinking about how much money you want to throw at it.

Verdict – are they mobsters? They are not mobsters but they are also not your best friends.

Are security questionnaires just security theater?

According to Miessler, you should slim down your security questionnaires to two questions:

“when was the last time you were breached (what happened, why, and how did you adjust)”?,
and “do you have security leadership and a security program?”.

The purpose of these questions is to judge if they have a reasonable approach to security. It is easy for people to lie on detailed but generic security forms, and they provide little value. To discover if a company is a metaphorical “axe murderer” the two questions above are enough, argues Miessler. He may have a point. Take for example a typical security questionnaire favorite: “does your company use firewalls to safeguard computers from online attacks?” Everyone will answer “yes”. Does that change our knowledge about their likelihood of being hacked? Not one bit.

Of course, lying on a short questionnaire with Miessler’s 2 questions is not more difficult than lying on a long and detailed questionnaire. Most companies would not admit anything on a questionnaire like this, that is not already publicly known. It is like flying to the US a few years ago where they made you fill out an immigration questionnaire with questions like “are you a terrorist?” and “have you been a guard at a Nazi concentration camp during WWII”. It is thus a good question if we can even just scrap the whole questionnaire. If the vendor you are considering is a software firm, at least if it is a “Software as a Service” or another type of cloud service provider, they are likely to have some generic information about security on their web page. Looking up that will usually be just as informative as any answer to the question above.

Verdict: Security questionnaires are mostly useless – here I agree with Miessler. I think you can even drop the minimalist axe murderer detection variant, as people who lie on long forms probably lie on short forms too. Perhaps a good middle ground is to first check the website of the vendor for a reasonable security program description, and if you don’t see anything, then you can ask the two questions above as a substitute.

Stay away from extremely bad practice

Staying away from companies with extremely bad practice is a good idea. Sometimes this is hard to do because business needs a certain service, and all potential providers are horrible at security. But if you have a choice between someone with obviously terrible security habits and someone with a less worrying security posture, this is clearly good advice. Good ways to check for red flags include:

Create a user account and check password policies, reset, etc. Many companies allow you to create free trial accounts, which is good for evaluating security practices as well.
Check if the applications are using outdated practices, poor configuration etc.
Run sslscan to check if they are vulnerable to very old crypto vulnerabilities. This is a good indicator that patching isn’t exactly a priority.

Verdict: obviously a good idea.

Assume the vendor is breached and create a risk assessment

This turns to focus on your own assets and risk exposure. Assuming the vendor is breached is obviously a realistic start. Focusing on how that affects the business and what you can do about it, makes the vendor risk assessment about business risk, instead of technical details that feel irrelevant.

Miessler recommends:

Understand how the external service integrates into the business
Figure out what can go wrong
Decide what you can do to mitigate that risk

This is actionable and practical. The first part here is very important, and to a large degree determines how much effort it is worth putting into the vendor assessment. If the vendor will be used for a very limited purpose that does not involve critical data or systems, a breach would probably not have any severe consequences. That seems acceptable without doing much about it.

On the other hand, what if the vendor is a customer relationship management provider (CRM), that will integrate with your company’s e-commerce solution, payment portal, online banking and accounting systems? A breach of that system could obviously have severe consequences for the company in terms of cost, reputation and legal liabilities. In such a case, modeling what could happen, how one can reduce the risk and assessing whether the residual risk is acceptable would be the next steps.

Shared responsibility – not only in the cloud

Cloud providers talk a lot about the shared responsibility model (AWS version). The responsibility for security of software and data in the cloud is shared between the cloud provider and the cloud customer. They have documentation on what they will take care of, as well as what you as a customer need to secure yourself. For the work that is your responsibility, the cloud provider will typically give you lots of advice on good practices. This is a reasonable model for managing security across organizational interfaces – and one we should adopt with other business relationships too.

The most mature software vendors will already work like this, they have descriptions of their own security practices that you can read. They also have advice on how you should set up integrations to stay secure. The less mature ones will lack both the transparency and the guidance.

This does not necessarily mean you should stay away from them (unless they are very bad or using them would increase the risk in unacceptable ways). It means you should work with them to find good risk mitigations across organizational interfaces. Some of the work has to be done by them, some by you. Bringing the shared responsibility for security into contracts across your entire value chain will help grow security maturity in the market as a whole, and benefit everyone.

Questionnaires are mostly useless – but transparency and shared responsibility is not.

In Miessler’s vendor security 2.0 post there is a question about what vendor security 3.0 will look like. I think that is when we have transparency and shared responsibility established across our entire value chain. Reaching this cybersecurity Nirvana of resilience will be a long journey – but every journey starts with a first step. That first step is to turn the focus on how you integrate with vendors and how you manage the risk of this integration – and that is a step we can take today.

CCSK Domain 2: Governance and Enterprise Risk Management

May 23, 2019 Håkon OlsenLeave a comment

Governance and risk management principles remain the same, but there are changes to the risk picture as well as available controls in the cloud. We need in particular take into account the following:

Cloud risk trade-offs and tools
Effects of service and deployment models
Risk management in the cloud
Tools of cloud governance

A key aspect to remember when deploying services or data to the cloud is that even if security controls are delegated to a third-party, the responsibility for corporate governance cannot be delegated; it remains within the cloud consumer organization.

Cloud providers aim to streamline and standardize their offerings as much as possible to achieve economies of scale. This is different from a dedicated third-party provider where contractual terms can often be negotiated. This means that governance frameworks should not treat cloud providers with the same approach as those dedicated service providers allowing for custom governance structures to be agreed on.

Responsibilities and mechanisms for governance is regulated in the contract. If a governance need is not described in the contract, there exists a governance gap. This does not mean that the provider should be excluded directly, but it does mean that the consumer should consider how that governance gap can be closed.

Moving to the cloud transfers a lot of the governance and risk management from technical controls to contractual controls.

Cloud governance tools

The key tools of governance in the cloud are contracts, assessments and reporting.

Contracts are the primary tools for extending governance into a third party such as a cloud provider. For public clouds this would typically mean the terms and conditions of the provider. They are the guarantee of a given service level, and also describes requirements for governance support through audits.

Supplier assessments are important as governance tools, especially during provider selection. Performing regular assessments can discover if changes to the offerings of the cloud provider has changed the governance situation, in particular with regard to any governance gaps.

Compliance reporting includes audit reports. They may also include automatically generated compliance data in a dashboard, such as patch level status on software, or some other defined KPI. Audit reports may be internal reports but most often these are made by an accredited third party. Common compliance frameworks are provided by ISO 27017, ISO 38500, COBIT.

Risk management

Enterprise risk management (ERM) in the cloud is based on the shared responsibility model. The provider will take responsibility for certain risk controls, whereas the consumer is responsible for others. Where the split is depends on the service model.

The division of responsibilities should be clearly regulated in the contract. Lack of such regulation can lead to hidden implementation gaps, leaving services vulnerable to abuse.

Service models

IaaS mostly resembles traditional IT as most controls remain under direct management of the cloud consumer. Thus, policies and controls do to a large degree remain under control of the cloud consumer too. There is one primary change and that is the orchestration/management plane. Managing the risk of the management plane becomes a core governance and risk management activity – basically moving responsibilities from on-prem activities to the management plane.

SaaS providers vary greatly in competence and the tools offered for compliance management. It is often possible to negotiate custom contracts with smaller SaaS providers, whereas the more mature or bigger players will have more standardized contracts but also more tools appropriate to governance needs of the enterprise. The SaaS model can be less transparent than desired, and establishing an acceptable contract is important in order to have good control over governance and risk management.

Public cloud providers often allow for less negotiation than private cloud. Hybrid and community governance can easily become complicated because the opinions of several parties will have to be weighed against each other.

Risk trade-offs

Using cloud services will typically result in more trust put in third-parties and less direct access to security controls. Whether this increases or decreases the overall risk level depends on the threat model, as well as political risk.

The key issue is that governance is changed from internal policy and auditing to contracts and audit reports; it is a less hands-on approach and can result in lower transparency and trust in the governance model.

CSA recommendations

Identify the shared responsibilities. Use accepted standards to build a cloud governance framework.
Understand and manage how contracts affect risk and governance. Consider alternative controls if a contract leaves governance gaps and cannot be changed.
Develop a process with criteria for provider selection. Re-assessments should be regular, and preferably automated.
Align risks to risk tolerances per asset as different assets may have different tolerance levels.

#2cents

Let us start with the contract side: most cloud deployments will be in a public cloud, and our ability to negotiate custom contracts will be very limited, or non-existing. What we will have to play with is the control options in the management plane.

The first thing we should perhaps take note of, is not really cloud related. We need to have a regulatory compliance matrix in order to make sure our governance framework and risk management processes actually will help us achieve compliance and acceptable risk levels. One practical way to set up a regulatory compliance matrix is to map applicable regulations and governacne requirements to the governance tools we have at our disposal to see if the tools can help achieve compliance.

Regulatory source	Contractual impact	Supplier assessments	Audits	Configuration management
GDPR	Data processing agreement	Security requirements GDPR compliance	Data processing acitvities audits	Data retention Backups Discoverability Encryption
Customer SLA	SLA guarantees		Uptime reporting
ISO 27001		Certifications	Audit reports for certifications	Extension of company policies to management plane

Based on the regulatory compliance matrix, a more detailed governance matrix can be developed based on applicable guidance. Then governance and risk management gaps can be identified, and closing plans created.

Traditionally cloud deployments have been seen as higher risk than on-premise deployments due to less hands-on risk controls. For many organizations the use of cloud services with proper monitoring will lead to better security because many organizations have insufficient security controls and logging in their on-premise tools. There are thus situations where a shift from hands-on to contractual controls is a good thing for security. One could probably claim that this is the case for most cloud consumers.

One aspect that is critical to security is planning of incident response. To some degree the ability to do incidence response on cloud deployments depends on configurations set in the management plane; especially the use of logging and alerting functionality. It should also be clarified up front where the shared responsibility model puts the responsibility for performing incident response actions throughout all phases (preparation, identification, containment, eradication, recovery and lessons learned).

The best way to take cloud into account in risk management and governance is to make sure policies, procedures and standards cover cloud, and that cloud is not seen as an “add-on” to on-premise services. Only integrated governance systems will achieve transparency and managed regulatory compliance.

Top of the iceberg: politicians’ private email accounts and shadow IT

March 4, 2017 Håkon OlsenLeave a comment

In CISO circles the term “shadow IT” is commonly used for when employees use private accounts, devices and networks to conduct work outside of the company’s IT policies. People often do this because they feel they don’t have the freedom to get the job done within the rules.

If you deny your people a well-stacked toolbox, they will bring their own. That may not be the best solution for your security.

This is not only for low-level clerks and helpdesk ninjas: top level managers are known to do this a lot, including politicians. Hillary Clinton probably lost the presidential election at least partially due to her poor security awareness. Now VP Mike Pence has also been outed as “private email wielding pubic servant” – and he was hacked too. Why do people do this?

Reasons why people do their business in the IT shadows

I’ll nominate 3 main reasons why people tend to use private and unauthorized tools and services in companies and public service. Then let’s look at what we can do about it, because this is a serious expansion of the organization’s attack surface! And we don’t want that, do we?

I believe (based on experience) the 3 main reasons are:

The tools they are provided with are hard to use, impractical or not available
They do not understand the security implications and have not internalized what secure behaviors really are
The always-on culture is making the distinction between “work” and “personal” foggy; people don’t see that risks they are willing to take in their personal lives are also affecting their organizations that typically will have a completely different risk context

How to avoid the shadow IT rabbit hole of vulnerabilities

First of all, don’t treat your employees and co-workers are idiots. IT security is very often about locking everything down and hardening machines and services. If you go too far in this direction you make it very hard for people to do their jobs, and you can end of driving them into the far riskier practices of inventing their own workarounds using unauthorized solutions – like private email accounts. Make sure controls are balanced, and don’t forget that security is there to protect productivity – not as the key product of most organizations. Therefore, your risk governance must ensure:

Select risk-based controls – don’t lock everything down by default
Provide your employees with the solutions they need to do their jobs
Remember that no matter how much you harden your servers, the human factor still remains.

Second, make people your most important security assets. Build a security aware culture. This has to be done by training, by leadership and by grassroots engagement in your organization.

Third, and for now last, disconnect. Allow people to disconnect. Encourage it. Introduce separations between the private and what is work or for your organization. This is important because the threat contexts of the private sphere and the organizational sphere are in most cases very different. This is also the most difficult part of the management equation: allowing flexible work but ensuring there is a divide between “work” and “life”. This is what work-life balance means for security; it allows people to maintain different contexts for different parts of their lives.

Cybersecurity for boards – the short story

March 3, 2017March 3, 2017 Håkon OlsenLeave a comment

A few days ago I wrote a post on the lack of cybersecurity skills in corporate boards, and how to fix that. This became one of the most popular posts on the blog. That’s why I created this short summary video – that you can easily share with your top management and board members.

The take-aways are:

Build an information security management system with the most important policies, guidelines, procedures, change mangement and monitoring processes in place
Select reporting metrics that make sense in terms of the company strategy. Relate impact to financial, customer, organnization and learning, and internal process perspectives.
Use compliance to drive board focus: regulatory compliance is already central in goverannce work.
Focus on people when communicating – build a positive security culture by combining bottom-up and top-down approaches.

Thanks to Kenneth Holley and eForensics Magazine for sharing the board post! Great accounts to follow on Twitter!

How to build up your information security management system in accordance with ISO 27001

February 12, 2017February 12, 2017 Håkon Olsen8 Comments

Maintaining security is an ongoing process which requires coordinated effort by the whole organization. Without backing from the top management levels and buy-in through the ranks there is little chance of building up resilience against cyber attacks. As organization complexity increases and value creation becomes distributed it will be necessary to have an integrated approach to security; your company needs an information security management system. ISO 27001 is an international standard that sets requirements to such as system based on what has been internationally recognized as best practice.

ISO 27001 [external link] is a management system standard that follows many of the same principles as other ISO standards such as ISO 9001 for quality management. Assuming that the client has a ISO 9001 compliant system in place, the information security management system should be built on the existing processes and workflows. This means that existing auditing systems and reporting requirements should be appended, rather than building everything from scratch.

The following are key elements of information security management system establishment. First we look at the activities that need to be performed in the order of appearance of requirements in ISO 27001. Afterwards, we summarize the bare minimum that you will have to do in a table.

Main requirements and activity descriptions

Context mapping

(Ref. ISO 27001 Section 4)

The context mapping consists of creating an overview of the value chain as well as the internal requirements to security (you can read more about that in What are the things that need to be considered when doing a risk assessment?), and how this affects the information security risk. Key activities:

External stakeholder definitions
- Who are the main customers
- Who are the main suppliers
- Under which regulatory regimes does the organization operate?
- Who are the main threat actors based on the external context? (Script kiddies, hacktivists, cyber criminals, nation states, etc.)
Internal stakeholder definitions
- Who are the system owners?
- Who are the system users?
- Which process owners depend the most on the information assets?
- Who are responsible for maintaining security?
- Identify main information assets
- What are the critical information objects?
- Why are they critical in the context of operations?
- Are there assets that require security due to external stakeholder situations (legal or commercial requirements, or due to risk drivers)

The most efficient approach for this type of context development is a working meeting with the organization’s top management where these key issues are identified.

Building a management system requires the involvement from the whole organization. Focusing on business strategy, key stakeholders and the value chain in terms of core competence, contracts with the supply chain and how to drive compliance (e.g. through auditing) is key to securing the organizations’ assets in the long run.

Policy development and leadership

(ISO 27001 Section 5)

Top management must be involved in policy development, and promote its integration in the overall management system of the organization
A policy should be developed and be sanctioned and signed by top management. The policy shall include the following:
- Policy objectives
- Should commit the organization to compliance with infosec requirements, and to continuous improvement. It should therefore refer to the organizations existing systems for compliance measurement and continuous improvement processes, as well as to internal information security standards with more practical requirements.
- The policy shall be documented and made available and communicated to all users
Top management shall assign responsibility and authority for follow-up of information security, and for reporting to top management. In most organizations a single role is recommended for this, and a person competent in both the organization’s core activity and in information security principles should take this role. In most commercial organizations this role is designated as CISO.

Policy objectives should conform to the requirements of Clause 6.3 of ISO 27001. In order to identify these goals when building a new system it is recommended to write the policy after an initial risk and vulnerability assessment has been performed.

Recommended practice is to develop the policy in cooperation with the assigned CISO (if existing at this point). A policy document should be written and discussed with top management before it is updated. The policy should be dated, and an expiry date should be set in order to guarantee regular reviews (this is not an ISO 27001 requirement but is considered good practice for security critical process documents).

Information security risk management planning

(ISO 27001 Section 6)

Define a process for information security risk assessment. The recommended elements of this process:
- Requirements to documentation of [USERS, HARDWARE, SOFTWARE, NETWORKS]
- Requirements to performing risk assessments
- Risk acceptance criteria. It is recommended to keep this at a coarse level and use qualitative descriptors
- HAZID-type risk identification (use of guidewords)
- Control planning methodology (ref. to Annex A of ISO 27001)
Perform a risk assessment for all applicable systems (Scope definition à HAZID à Risk ranking à Risk treatment planning)
Produce a statement of applicability for the controls in Annex A of ISO 27001
Formulate infosec objectives (ref policy development). These objectives should be measurable, or at least possible to evaluate with respect to performance. The objectives should align well with the overall criticality of the information assets (ref. risk context). Annex A of ISO 27001 is a good guidance point for developing objectives. Also, the organization should not choose objectives that are inconsistent with the maturity and capabilities of the organization.

The risk assessment procedure should be written in a practical way, such that the organization can apply it with the available resources. It should include examples of format for reporting, and also the recommended guidewords/threat descriptors.

A key difficulty for infosec risk assessments is the risk ranking. There are several ways this has been approached, varying from using “complexity of attack vector” as an proxy for probability and generic ratings for impact, to context related impact assessments in operationally relevant categories such as revenue loss, legal and litigation consequences, or reputation loss. The probability dimension can also be treated using aggressor profiling techniques, which is recommended for sophisticated organizations with a good understanding of the threat landscape. You can read more about that technique in this blog post from 2015: https://safecontrols.blog/2015/09/08/profiling-of-hackers-presented-at-esrel-2015/

Support

(ISO 27001 Section 7)

The organization must perform a competence requirements mapping with respect to infosec for the various roles in the organization. This work should be performed in cooperation with the organization’s HR department, and set verifiable requirements for groups of employees. Responsibility for following up this type of competence should be given, preferably to the HR director or similar. Typical employee groups would be:
- Senior leadership
- HR and middle management
- Information system users
- IT personnel
- Specific roles (CISO, internal auditor, etc.)
The organization must develop an awareness program. The awareness program should as a minimum include:
- Making employees aware of the policy
- Why complying with the policy and the procedures is necessary and beneficial
- Implications of non-compliance (up to and including employee termination and criminal charges in serious circumstances, depending on local legislation)
Information security aspects should be included in the communication plans for both internal and external communication.

For document control and similar processes, it is assumed that the organization has an appropriate system. If not, see ISO 27001 Section 7, Clause 7.5.3, as well as ISO 9001 requirements).

The awareness program should be made the responsibility of either the CISO or the training manager /HR. These departments must cooperate on this issue.

The communication plan for information security can be integrated in other communication plans but shall be approved by the CISO. It is recommended to develop a specific plan for information security that other communication plans can refer to. This is especially relevant for communications during incident handling, which may require tight stakeholder cooperation and maintaining good public relations and media contacts.

Operations and Performance Monitoring

(ISO 27001 Section 8-9)

The organization must implement and document the performance of the risk mitigating controls. A lot of the proof can be extracted from data from technological barrier functions, whereas other measures may be necessary to document organizational controls.
Information security aspects should be included in the organizations change management procedures (ref. ISO 9001 requirements)
Information security monitoring should be implemented based on control and objectives
Information security auditing should be included in the internal auditing program. It is recommended to build up on the existing system, and to include requirements to competence for the subject matter expert assisting the head auditor (ref. back to competence management and HR processes). Some extra reading about auditing and what it is good for can be found here, but for the context of reliability engineering. It should be equally applicable in the context of cybersecurity: Why functional safety audits are useful
Include infosec in management review. In particular ensure efficient reporting on infosec objectives. It is recommended to create a simple and standardized reporting format (e.g. a dashboard) for this use.

Continuous Improvement

(ISO 27001 Section 10)

Include infosec into the existing non-conformance system
Assign CISO as owner of infosec related deviations

Activity summary and sequence

Building a management system requires multiple activities that have interdependencies, as well as dependencies on other management system artifacts. The following sequence is a suggested path to developing an information security management system from scratch in a robust organization.

Note that it should be expected that some iterations will be needed, especially on:

Policy and objectives
Risk assessment procedure and risk and vulnerability study (the procedure is updated based on experience with the method)
Objectives and measurements will need to be reviewed and updated based on experience

Note also that a consultant has been included in the “People” category. For organizations that do not have sufficient in-house competence in management system development it can be beneficial to contract a knowledgeable consultant to help with the project. For organizations with sufficient in-house capacity this is not necessary, and it is not a requirement for compliance with ISO 27001.

Main activity	Sub activities	Inputs	Outputs	People
Context development	Stakeholder mapping	Customers/users, organization charts, suppliers, partner lists, etc.	Information in technical note on Context: stakeholders. Should include who, why, what and how with respect to the information security risk.	Top management Consultant
Context development	Inventory mapping	Network topologies, asset lists, document systems	Prioritized inventory description as section in technical note on Context.	CISO IT department Archiving department Consultant
Context development	Threat actor assessment	Outputs from previous activities. News and general media. Experience from previous incidents. Open security assessments from police and intelligence communities.	List of threat actor categories with descriptions of motivations and capabilities.	CISO Consultant
Risk procedure development			Risk assessment procedure document	CISO Consultant
Risk assessment	Scope definition for risk assessment	Context note with inventory. Topology drawings. Organization charts. Use cases.	Scope presentations	Consultant System owners CISO
Risk assessment	Risk identification	Use of guidewords for each scope node, ref risk assessment procedure.	Risk identification table (HAZID table)	Consultant System owners CISO
Risk assessment	Risk evaluation	HAZID table.	Risk ranking.	Consultant System owners CISO
Risk assessment	Mitigation planning (including ISO 27001 Annex A review)	HAZID table with risk ranking.	List of actions and controls to be evaluated or implemented.	Consultant System owners CISO
Risk assessment	Reporting	HAZID table and risk mitigation results.	Risk and vulnerability report.	Consultant
Statement of applicability	Review each control in Annex A	Context note. Risk and vulnarbility report.	Statement of applicability (report)	Consultant CISO
Objectives development	Suggest objectives based on previous activities and maturity of the organization	Risk assessment, context, statement of applicability	Information security objectives, including measurement and review requirements in technical note or procedure.	Consultants
Objectives development	Review of objectives with key stakeholders	Objective note.	Revised objective note.	CISO Top management Consultant
Policy development	Develop draft policy for information security.	Objectives, statement of applicability, risk and vulnerability report, context, policy templates.	Draft policy.	Consultant CISO
Policy development	Review draft policy in meeting with top management. Top leadership needs to be involved and take ownership, headed by the CISO.	Draft document	Revised policy	Top management CISO Consultant
HR Integration: competence management	Develop competence requirements for roles	Role descriptions	Updated competence requirements in role descriptions	HR CISO Consultant
Awareness program	Develop awareness program, tailored to competence requirements of groups.	Updated role descriptions	Awareness program plan	HR/Training responsible CISO Consultant
Internal auditing requirements	Update internal auditing requirements	Infosec policy and procedures, objectives	Updated audit plans and competence requirements for subject matter expert	CISO Internal auditor Consultant
Other integrations	Update change management system and management’s annual review reporting requirements	Infosec policy and objectives	Updated change management procedure Updated reporting format to top management.	CISO (recommend that this is done internally unless consultant’s assistance is needed)

After the management system has been established, it is recommended to perform an internal requirements audit to identify gaps.

After the system has been in operation for 6 months an internal security audit with focus on evidence of use is recommended.

Summing up what you just read

You have determined your company needs a security management system. This blog post gives you a blueprint for building one from scratch. Keep in mind that the system with its processes, governing documents and role descriptions only provide a framework to work within. Key to getting value from this process is starting to use the system.

Building a management system from scratch is a big undertaking, and for many companies it makes more sense to do it piece by piece. Start with a minimum solution, start using it, and improve on the processes and documents based on your experience. That is much better than trying to build the system to be fully compliant from day 1 – and you will start to see real benefits much sooner.

Thinking about risk through methods

January 23, 2017 Håkon OlsenLeave a comment

Risk management is a topic with a large number of methods. Within the process industries, semi-quantitative methods are popular, in particular for determining required SIL for safety instrumented functions (automatic shutdowns, etc.). Two common approaches are known as LOPA, which is short for “layers of protection analysis” and Riskgraph. These methods are sometimes treated as “holy” by practicioners, but truth is that they are merely coginitive aids in sorting through our thinking about risks.

13768080_1067660556651700_1098663203_n — Riskgraph #sliderule – methods are formalisms. See picture on Instagram

In short, our risk assessment process consists of a series of steps here:

Identify risk scenarios
Find out what can reduce the risk that you have in place, like design features and procedures
Determine what the potential consequences of the scenario at hand is, e.g. worker fatalities or a major environmental disaster
Make an estimate of how likely or credible you think it is that the risk scenario should occur
Consider how much you trust the existing barriers to do the job
Determine how trustworthy your new barrier must be for the situation to be acceptable

Several of these bullet points can be very difficult tasks alone, and putting together a risk picture that allows you to make sane decisions is hard work. That’s why we lean on methods, to help us make sense of the mess that discussions about risk typically lead to.

Consequences can be hard to gauge, and one bad situation may lead to a set of different outcomes. Think about the risk of “falling asleep while driving a car”. Both of these are valid consequences that may occur:

You drive off the road and crash in the ditch – moderate to serious injuries
You steer the car into the wrong lane and crash head-on with a truck – instant death

Should you think about both, or pick one of them, or another consequence not on this list? In many “barrier design” cases the designer chooses to design for the worst-case credible consequence. It may be difficult to judge what is really credible, and what is truly the worst-case. And is this approach sound if the worst-case is credible but still quite unlikeley, while at the same time you have relatively likely scenarios with less serious outcomes? If you use a method like LOPA or RiskGraph, you may very well have a statement in your method description to always use the worst-case consequence. A bit of judgment and common sense is still a good idea.

Another difficult topic is probability, or credibility. How likely is it that an initiating event should occur, and what is the initating event in the first place? If you are the driver of the car, is “falling asleep behind the wheel” the initating event? Let’s say it is. You can definitely find statistics on how often people fall asleep behind the wheel. The key question is, is this applicable to the situation at hand? Are data from other countries applicable? Maybe not, if they have different road standards, different requirements for getting a driver’s license, etc. Personal or local factors can also influence the probability. In the case of the driver falling asleep, the probabilities would be influenced by his or her health, stress levels, maintenance of the car, etc. Bottom line is, also the estimate of probability will be a judgment call in most cases. If you are lucky enough to have statistical data to lean on, make sure you validate that the data are representative for your situation.Good method descriptions should also give guidance on how to do these judgment calls.

Most risks you identify already have some risk reducing barrier elements. These can be things like alarms and operating procedures, and other means to reduce the likelihood or consequence of escalation of the scenario. Determining how much you are willing to rely on these other barriers is key to setting a requirement on your safety function of interest – typically a SIL rating. Standards limit how much you can trust certain types of safeguards, but also here there will be some judgment involved. Key questions are:

Are multiple safeguards really independent, such that the same type of failure cannot know out multiple defenses at once?
How much trust can you put in each safeguard?
Are there situations where the safeguards are less trustworthy, e.g. if there are only summer interns available to handle a serious situation that requires experience and leadership?

Risk assessmen methods are helpful but don’t forget that you make a lot of assumptions when you use them. Don’t forget to question your assumptions even if you use a recognized method, especially not if somebody’s life will depend on your decision.

Safety versus convenience

August 12, 2015 Håkon OlsenLeave a comment

Risk based asset management frameworks force us to be systematic in our approach. Multiple layers of defense are commonly applied to mitigate risks down to what we see as an acceptable level. In many cases it will feel like each layer of defense is a layer of inconvenience.

Do we maximize the number of spikes (or layers of protection) to feel safe?

The ALARP principle is often used to evaluate if a certain defense layer is worth the investment. This type of analysis tends to be CAPEX focused. Very cumbersome operations tend to make people invent bypasses that are more convenient. In addition to investment cost, maybe we should also include the effect of the mitigation solution on convenience and how humans react to it, in addition to cost? If people bypass the intended operating procedure – the result of the new risk mitigation investment could be an increase in the overall risk.

safecontrols

Risk management, reliability and security

Tag: risk management