Summary

The basis upon which this multi-part segment builds from is taking our knowledge as a user of technology and applying it toward security awareness. Coming from a background in technology is a benefit for many reasons, but foremost is that understanding how people use technology is as important to security as understanding the technology itself.

The overall focus of this multi-part segment will be understanding core elements for initial or further learning into the cybersecurity space.

Topic

Understanding the difference between vulnerabilities, threats, and risk.

Understanding Risk

Our job as practitioners is to interpret disparate data in such a way that allows us to establish risk profiles. When evaluating individual or combined technologies it is far more likely that you will find a system with risks than one without, and those risks may be derived from one or many sources within a system.

Understanding surface risk in a system is dependent upon knowing two pieces of information; vulnerabilities of the system and threats to it. Vulnerabilities are weaknesses that may be inherent or conditional, while threats are people or things that may exploit those vulnerabilities.

When it comes to businesses we need a little more data because we need to be able to classify and convey the severity of this risk as something measurable to the business. So once we know the surface risk we evaluate how critical the data or systems that hold this risk are to business functions, and then assess compensating controls that may diminish damages from a vulnerability. From this perspective we should be able to classify and communicate the severity of this risk to the business, and then prioritize a response.

Example #1 - You!

An easily available resource, let us focus on yourself as a daily driver of your computer. Whether you use Windows, MacOS, or Linux some aspect of your computer is being provided or maintained by an upstream entity. We will focus on this circumstance for this example.

• Vulnerability: An upstream entity unknowingly sends a malicious update to a popular software you use.
• Threat: A threat actor (criminal) installs a keylogger on affected systems.
• Risk: Your banking data is exposed publicly.

In this circumstance we identify that some popular application could be compromised, and they install a keylogger on personal computers. On the surface this could be pretty bad if you do a lot of banking or work from your personal computer.

• Determining Severity:
  • The severity for this type of event will likely start “high”, because we know the likelihood of being affected if we are a user of the application is great. We then adjust up or down depending on how we judge our security posture against this threat.
  • Reductions:
    • Do you bank from your personal machine?
    • Do you access work systems or documents from your personal machine?
    • If either or both answers is “no”, then the risk may be reduced.
  • Controls:
    • Do you run anti-virus on your personal machine?
    • Do you have multi-factor authentication for banking/work login?
    • Do you use unique passwords for every website?
    • If some or all answers are “yes”, then the risk may be reduced.

If you don’t use your personal computer for banking or work, and you do run anti-virus and use MFA, then the likelihood of you being adversely impacted is probably much lower than someone who uses their personal computer for everything. So for this example, the surface risk would be high, but the measured risk may be closer to “low” or “moderate”. You would still want to be proactive and rotate passwords regardless.

Example #2 - Web Application

Web applications are fairly ubiquitous in the modern world. Many phone applications, home appliances, and even cars run them as a component of their user interface or as extended functionality. For this example, we will focus on a fake website called PassportPipeline, which helps expedite the passport application process for people who don’t have the time or energy to do it themselves.

PassportPipeline is run by a small business, and so they only have one IT systems administrator (sysadmin) to manage their cloud infrastructure. The IT sysadmin also tends to wear a security hat when it comes to patching and configuration standards. Today our IT sysadmin gets asked to join a morning check-in meeting with the DevOps team. Upon joining, our IT sysadmin is notified of a potential issue with software the DevOps team uses to manage their website.

One of the developers for PassportPipeline happens to be security conscious, and regularly checks security bulletins published for software the DevOps team uses for managing the website. This morning they noticed that there is a new vulnerability for their CMS (Content Management System), that gives unauthenticated users with access to the admin portal the ability to execute commands on the server hosting the CMS as an administrative user.

What’s more, DevOps does not think they will be able to patch to a fixed version for at least 4 weeks due to a freeze in code changes the CIO implemented last month in an attempt to improve platform stability metrics. They’ve asked the IT sysadmin to review the configuration on the servers and let them know of any potential changes they could make to better secure the servers until the updated code can be deployed.

• Vulnerability: Anyone with direct access to the website CMS admin interface could run commands as an administrator on the underlying server.
• Threat: There are many cyber criminals who exploit exposed administrative interfaces for botnets, ransomware or credit card fraud.
• Risk: Exposure of customer private data, or impact to platform operations.

Since the IT sysadmin is already fairly knowledgable about the server configuration, they are aware of a few things:

• There are load balancers between the internet and the website servers
• Only HTTP ports are allowed to the website servers from the load balancers
• The website and the CMS are on the same servers, and;
  • Server remote administration is only possible from the IT jump host
  • The website and CMS have different URLs (www.PassportPipeline.com and cms.PassportPipeline.com)
• DevOps has their own jump host for managing test environments

Lets take pause for a moment, and think about this situation before chasing down severity. Put yourself in this situation, and consider what questions you might have in addition to the ones below.
What steps could you take to validate the vulnerability?
What questions could you ask the DevOps team to better understand the risk?
Are there any technologies inline with the website that could offer protection?

• Determing Severity:
  • The severity for this type of event will likely start as “high”, because we know that our current software is impacted.
  • The IT sysadmin wants to validate if they are vulnerable from the internet. They check to see if the CMS admin portal is available from their personal computer – it is. (severity remains high)
  • The IT sysadmin checks the load balancers, which are currently set to forward traffic for all traffic matching *.PassportPipeline.com (severity remains high)

The IT sysadmin considers this to be a critical problem, as there is no control in place to prevent someone from abusing the new vulnerability. Some action must be taken in short time to prevent abuse of their platform.

Unfortunately just blocking traffic to the CMS also means blocking customer traffic to the platform since they are hosted on the same servers. However, it does appear that there is an option to only forward specific hostnames (URLs) in the load balancer.

The IT sysadmin asks the DevOps team how they access the CMS portal today. The DevOps team says they use their jump host to access the admin portal directly (they do not use the load balancer).

The IT sysadmin puts together a change request, and gets approval to change the load balancers from wildcard “*” to “www”, which is approved by their management and DevOps leadership. The changes are implemented in an emergency change window, and the IT sysadmin verified the CMS website is no longer accessible from the internet.

Measured risk may be reduced slightly now, as someone must first have access to an adjacent server to exploit the vulnerability.

Given the period of unknown between the vulnerability being found and the IT sysadmin implementing a control, they would also likely need to take proactive measures to assess, monitor, and continuously evaluate the CMS environments for any suspicious activity while the DevOps team prepares to patch.

Takeaways:

• You won’t always know who or what the threat is. For these situations it is best to assume that someone has the means and want to do bad things, and to ask questions or take actions to build a clearer picture of whether or not a vulnerability could be exploited, and if so how easily.
• Do your best to estimate and communicate potential damages. The most compelling argument for security, and also the reason why most security work goes unseen, is damage prevention.
• Once you have a clear picture of the measured risk, and if the risk is enough to warrant action, then start from a place of simple solutions to problems. A technology you already use, or control you already implement is a good place to start.
• Don’t solution in a vacuum for changes that may impact stakeholders. You may take a swag at the 1st iteration or two of an idea, but let that idea aerate with your stakeholders. Getting buy-in is a team sport, and it’s easier when you have more players on your team.