Security at a Startup: How to Conduct a Practical Risk Analysis

Security at a start-up can be difficult in many different ways. These difficulties primarily come down to obtaining management buy-in and funding for something that can be seen as simply overhead costs. Risk analyses are a great way for everyone to understand the business a lot better from a practical security perspective, which can help with getting management buy-in. If done right, a risk analysis can also provide good estimates of how much the requisite security measures are likely to cost, which will help with getting the necessary funding. A risk analyses may sound like a daunting task, but one thing is for certain: starting regular risk analysis early in the company’s life makes most things much easier down the road.

What is a risk analysis?

A risk analysis is a systematic approach to reviewing your tangible and intangible assets and the risk posed to those assets. The analysis should address the different storage locations, controls, and processes related to those assets, explore the various threats likely to threaten the assets, measure any deficiencies in the security protecting the assets, and finally propose a way to correct, mitigate, or remove those deficiencies. Every environment is going to have vulnerabilities, threats, and associated risks, so it is critical that risk analysis is performed during regular intervals. This also helps the organization stay abreast of the current trends within the threat landscape—what is working today may not be sufficient tomorrow. Conducting an effective risk analysis takes some time and effort, so let’s jump right in and address the different steps you will need to take.

Information gathering

If this is the first time you are performing a risk analysis, you may have to gather a lot of data. Each risk analysis will hopefully get easier as you better understand your environment, the applications in use, and the controls in place. If you have a procurement process that includes vendor security analysis, you might already have a good amount of this data, but it is inevitable that something will slip through the cracks, and this is a perfect time to figure out what those elusive assets are. The following items will help with the information gathering process to make sure that all areas of the business have been thoroughly examined:

Determine your assets

Determine what your assets are and how important they are to your business. Assets can be anything that you see as having a value, either realized or potential. This can be computer equipment, customer data, financial data, intellectual property, reputation, etc.

Break things up

Break things up into departments and ask each department to identify the applications and processes that they use on a regular basis. As a whole, a risk analysis can be a daunting task; however, working as a team can ease the burden and bring in a range of perspectives, ultimately improving the outcome of the risk analysis overall.

Consider applicable laws

To conduct an effective risk analysis, it’s important that you learn the different laws and regulations that might apply to each department. For example, the sales department or Accounts Payable may be collecting credit card information from customers, so PCI compliance and call recording are going to be a factor. The DevOps team might be collecting logs that include personal information from a web application, so GDPR and the new California Consumer Privacy Act may apply.

Conduct interviews

After each department has returned their list of the applications and their associated controls, schedule an interview with the department heads to go over each item. Discuss what types of data are being processed with the applications being used and the associated levels/types of exposure. 

Performing the risk analysis

As we touched on before, performing a risk analysis means you determine the threats throughout your organization and the likelihood of those threats occurring. To be thorough, you should look at both internal and external threats. Ask yourself, what could someone do with the asset if it were compromised and what kind of damage would occur? There are going to be a lot of ‘what-ifs’ to consider and it can be easy to go overboard. Do your best to keep your ‘what-if’ scenarios pretty realistic. Someone walking into your office and stealing a computer is a realistic scenario. A unicorn crashing through a fourth story window and eating all the physical financial records probably isn’t... although that is a fun scenario to think about. Once you have your scenarios, they really aren’t any good until you can understand the actual risk they pose.  You will need to analyze each scenario and determine the actual risk it poses to your organization. There are a couple of different ways to look at your data to determine priorities and what kind of attention a risk should receive: qualitative and quantitative. We will dig a little bit deeper into each of these methods, but in a nutshell, a qualitative approach is going to give you your “I’m not afraid of bunnies” scenario, to your “the Apocalypse is coming and we are all doomed” scenario, whereas a quantitative approach is going to provide you with numbers that most executives are going to appreciate. You can use both approaches, and there are certain situations where using both would be appropriate.  You will want to decide which method is going to best convey the risk to key stakeholders. Whichever method you chose to use, a scale should be created to establish different levels of risk. Each risk should then be assigned a risk based on that scale. 

Qualitative vs Quantitative

Qualitative

A qualitative perspective essentially means the likelihood of an occurrence (ranging from unlikely to certain) and the consequence of an occurrence from insignificant to severe. This method is probably going to be the quickest and easiest method for most situations.

Quantitative

The quantitative method essentially helps you determine the ultimate cost of an incident and multiply that by a factor of how often it is likely that the incident will occur. This will provide a guideline on the maximum amount of money to allocate to protect that asset. A common formula for a quantitative analysis is Single Loss Expectancy multiplied by the Annualized Rate of Occurrence to get the Annualized Loss Expectancy. The Annualized Loss Expectancy is used to determine how much money should be put towards protecting the asset. Higher value assets or higher frequency threats will generally result in a higher Annualized Loss Expectancy and in turn a greater amount of security to protect that asset. The following is an example of a quantitative analysis:

Asset	Threat	Single Loss Expectancy	Annualized Rate of Occurrence	Annualized Loss Expectancy
Product Schematics	Stolen	$200,000	0.1  (once every 10 years)	$20,000
Customer Data	Accidental Disclosure	$25,000	0.2 (once every 5 years)	$5,000
Customer Data	Stolen	$1,000,000	0.05 (once every 20 years)	$50,000
Laptop	Stolen	$2,500	4.0  (four times per year)	$10,000
Application Data	Virus	$10,000	0.1 (once every 10 years)	$1,000

Types of Threats

When performing a risk analysis, it is very easy to get stuck on thinking about the different types of online threats, such as hacking, but there is more to security than just keeping data from being stolen. The three main pillars of security are confidentiality, integrity, and availability. When determining the different potential threats, think about these three different pillars and ask yourself the following questions:

• Confidentiality: Is it possible to break into a system to steal the data? Is the data accessible to employees or customers that shouldn’t have access to it, or are there ways for the data to be accidentally published or disclosed to a public website?

• Integrity: How might that data can be accidentally or intentionally altered? Are there processes in place to make sure you can trust a data source, or that someone has the right authority to request changes to access levels or configurations? 

• Availability: Is the data available when it is needed? Are there any possible disasters that could make the data unavailable (flood, arson, earthquake, AWS S3 outage)? If the power went out at a location, will you still be able to access necessary rooms and servers? Are there backups of important data so if a hard drive goes out, you can recover the data? Are the systems designed to fail gracefully, or are they likely to cause a failure cascade?

Risk management

After you determine your current risks (i.e. what can go terribly wrong), you then need to put together recommended solutions to correct (remediate) or reduce (mitigate) the risk. In many cases, these plans will likely require department heads and possibly corporate executives to sign-off. For major policy changes, you will need buy-in from the executive team.  Change is not often easy, and without support from the top business tier, you will find that employees may try to find ways around the policy, potentially making the situation even worse. Therefore, in order to make sure the changes have the best chance of being properly implemented and accepted, it is important that you have a detailed explanation of the potential threat and the associated risk so everyone can understand the need for change.  At a high level, there are four different courses of action that can be taken with each identified risk: accept the risk, mitigate the risk, eliminate the risk, or transfer the risk. Let’s take a closer look at each of those.

1. 1. Accept the risk: In many cases a risk will need to be accepted, meaning, you take no action or steps towards mitigating the risk. This is either because of the cost of implementation outweighs the cost of the risk, changes to the process would create a negative impact on a user experience, or there are no acceptable solutions currently available. A good analyst should be able to generally see when the recommendation should be to accept the risk. In some cases, a recommendation is turned down, but that is when the business decides that the risk is low enough that they feel comfortable accepting it or they have additional knowledge than the analyst. Although accepting the risk is a viable recommendation for an identified risk, it should be recommended as infrequently as possible.
   2. Reduce/Mitigate the Risk: You can choose to reduce or mitigate the risk by adding some measure that will decrease the overall risk by decreasing the frequency, or the level of damage of the threat. This is a good middle ground when the risk is too high to accept, but the cost to implement a full solution is inhibiting. These types of solutions should also come with a future plan to further reduce the risk, or even eliminate the risk when it becomes appropriate. 
   3. Remediate the Risk: Risk remediation should be the recommended solution whenever possible. Here, solutions are put in place to close gaps to correct the identified risk. In most cases, you may not be able to completely eliminate all risk; however, the goal is to drive the risk low enough that it is within the corporations risk appetite. These kinds of solutions involve implementing new hardware or software and implementing new policies or procedures.
   4. Transfer the Risk: To move the risk means putting the risk somewhere else. This can be done by purchasing insurance to cover the cost of a breach, or by placing the risk somewhere else by employing a service provider that will be in responsible for the controls to remediate or mitigate the identified threats.

Lessons learned

As with any other project, a post-mortem should be performed to determine what went well and what didn’t so you can improve your processes going forward. Here are some lessons that Lucid Software has learned over the years when it comes to conducting a risk analysis.

It requires a lot of time

Lucid’s security team has adopted an agile-like method of conducting work, meaning we work in two-week sprints. Prior to a sprint, we spend time planning out our work for the next couple of weeks, taking into consideration that inevitability that administrative and ad-hoc tasks will come up. Trying to plan a risk analysis within a two-week sprint turns out to be fairly difficult because there are many moving parts. Not only does it take a lot of time to collect, review, and report on everything, but it takes a lot of time to reach out to the various people required to help collect information and then finally determine what schedule will work for everyone.  A well-conducted risk analysis also requires time from other people within the company who may not be directly involved with the analysis. When trying to schedule times to meet with department heads to better understand their processes, we found that many of them were not able to meet with us for several weeks. This ultimately delayed the discovery process, which created a domino effect of delays.

It requires proper project planning

Since there are many parts to a risk analysis, it is essential that proper project planning takes place. Many times during our risk analysis, items came up that we had not thought of before, requiring us to make follow-up meetings and conversations with department heads, who were already busy. Keeping a record of your process and keeping notes and documentation will help speed things up in the future. One thing that helped was a written procedure surrounding how the risk analysis was to be performed, what things we needed to look at, and at what point the analysis was considered complete. Having a written guide will provide a template by which you can create your project plan. The following is a simple template that we used:

1. 1.  Identify assets, assign value, and identify user roles: Schedule meetings with each department head (or an appropriate delegate) and together create a list of all valuable assets owned, protected, or used by the department. This asset-first methodology helps to scope the assessment into most valuable assets used or owned by the company. Assets should be assigned a value (1 - Low value, 3 - Medium value, 5 - High value). Assigning a value helps the security team prioritize assets that would be most detrimental in loss. Another way to think of value is "impact of compromise."For each asset, identify owners, stewards, and users.  Identifying who owns and has access to the data helps identify if there are too many individuals involved, and who should truly have access and legal responsibility to protect the data.
   2. Identify threats and probability for medium and high-value assets: Assets face threats, that are usually a compromise of any of the three CIA aspects of security (confidentiality, integrity,  availability). For example, physical cash or other tangible assets can be stolen or damaged, resulting in a lack of availability of funds. Customer Personal Information could be exposed, modified, or deleted. Threats should be identified and probability evaluated in conjunction with existing mitigating factors.Finally, an impact grade should be assigned, detailing how "bad" it would be for the company if the threat were realized.
   3. Identify gaps between mitigating factors and the risks posed by the threats and asset values: Vulnerabilities are the gaps where mitigating factors or controls are insufficient to accommodate the threats. These should be prioritized based on the impact/value and probability.
   4. Prepare a remediation plan: For all identified vulnerabilities, create a proposed remediation plan that outlines the vulnerabilities and what recommended steps should be taken, and if possible, any identified costs for the proposed solution.
   5. Obtain approval:The results of the risk assessment must be reviewed and approved by senior management. This ensures that senior management is continually kept aware of the risks associated with existing assets. Approval can include a signed copy of the assessment, a digital signature on the digital assessment, or an email acknowledging receipt and acceptance of the assessment.

Pay attention to the calendar

As part of your project planning, you need to pay attention to the schedules of the others involved in the analysis. As mentioned earlier, we found that several people were not available to be able to meet and discuss their processes. It turns out that the analysis was scheduled during a busy time of the year where financial audits and other end-of-year activities were being performed. Pay attention to the calendar when scheduling your analysis and plan accordingly. Keep in mind holidays, summer vacations, fiscal years, sales events, end-of-quarter deadlines, and large conferences. You may not be able to avoid all of these at the same time, but at least be mindful of them and set the right expectations when creating the schedule for the analysis. You may need to stretch out the discovery phase in order to meet with all the individuals you need to meet with.

Determine threats

One of the most difficult parts of conducting a risk analysis can be thinking about all of the different threats that an asset might face. This was no exception for Lucid. In order to break things up, we broke threats up into internal threats and external threats. We also fell into the trap where rather than finding a threat, we were focusing on the consequence of a compromise of that asset. While this is good information to know, it did not help us in evaluating the current security measures and providing good viable solutions. Because of the confusion of what certain terms meant and how they were used, we documented better definitions of “asset”, “asset owner”, “asset steward”, “threat”, “vulnerability”, and “risk”. These clearer definitions helped everyone involved better understand what we were trying to protect, who is in charge of protecting the asset, and what the true threats and vulnerabilities were. 

Conclusion

A risk analysis, when done right, can add significant visibility into the security posture of your business, allowing you to fix gaps so you can further protect your data and to give executives the information they need to be advocates for the security program. Hopefully this has been informative, and you feel more confident in your capability to carry out improved risk analysis and risk assessments at your own organization.