Performing an operational risk analysis

- [Narrator] Before you deploy to production, you want to make make sure you've identified and address the operational risks. You can accomplish this by performing an operational risk analysis. We've talked about assessing and analyzing risk in previous videos. When you perform a risk analysis, you follow a defined process in an effort to determine whether or not something bad might happen. An operational risk analysis focuses on whether or not those bad things might disrupt not just your application, but also the business processes that your app was designed to support. When performing an operational risk analysis you want to look at more than just the application code. You want to include everything in the deployment environment. And by deployment environment I mean, all of the infrastructure components that the app relies on, this could include web servers, databases, network appliances, virtual machines, containers, anything and everything that the app needs in order to function. A quick way to start your operational risk analysis is by comparing your deployment environment to the apps functional requirements. I've worked on projects where the project team tried to come in under budget by cutting infrastructure components from our deployment environment. What might seem like a good idea in the short term can result in operational failures in the longterm. The deployment environment should also comply with your organization security policies and standards. Those policies exist for multiple reasons, with risk mitigation and regulatory compliance at the top of the list. A deployment environment that fails to comply with security policies and standards runs a greater risk of being compromised or taken offline. When an app is deployed to production, one often overlooked risk is whether or not the people using the app understand what they're supposed to do. Making an assumption that administrators and users will inherently understand how the app works introduces an operational risk that could easily be addressed. Depending on the complexity of your application, the administrator functions can range from simple tasks like user and password creation to more complex tasks like configuring integrations with other applications. At a minimum, your administrators should receive training on what a secure configuration looks like. Consider the access management config for example, things like password complexity and multifactor authentication. Do the admins know how to configure these items? The more importantly, do they know how to configure them in compliance with your organization security policies? Admin should also receive training on how to monitor the health of the application and its underlying infrastructure. If your admins know how to identify indicators of a possible failure in advance, they have the opportunity to proactively address those indicators before the app become slower, unresponsive. And as platforms and APIs become more and more popular with enterprise applications, your admins will also benefit from training on how to securely configure integrations between your application and those platforms. On the topic of integration, there are a few controls you can focus on that will help your admins understand how to securely integrate with other systems and applications while reducing operational risk. First and foremost, encrypt wherever possible. If an integration allows for unencrypted communication channels, you should avoid those channels in order to avoid the risk of exposing credentials or sensitive data. That said encryption comes with a price, namely managing those encryption components. Encryption keys and certificates are foundational to enabling encrypted communication channels. But where will you store those keys and certs? How will you change them when the need arises? In addition to encryption management, secrets management is another key component of secure system integration. By secrets, I'm referring to things like passwords, tokens and API keys. An attacker with access to your secrets could potentially create their own integrations. To protecting those secrets is an important step in mitigating those risks. We'll talk about secrets in more detail in a later video. Although well-designed apps are likely to have an intuitive user interface, your user should still receive some training on how to navigate the application. A user who doesn't receive this training might bypass certain screens or functions ones that are critical to business processes, which inadvertently introduces a business logic risk. That training on the user interface will be much more effective if it's developed and delivered with a focus on how the UI aligns with existing business processes. Users may be intimately familiar with the business processes themselves but they don't necessarily understand how those processes have been implemented in the app until they've received that training. One other user training opportunity that can have a significant impact on operational risk is how the users access the application. This includes everything from selecting a strong password to enabling multi-factor authentication to accessing the application over secure networks. They don't need all the technical details, they just need to understand enough to make an informed decision about how to protect those credentials. Otherwise, a malicious actor might be able to log in with compromised credentials and cause all sorts of damage. One recent improvement to the CSSLP Body of Knowledge is an increased focus on control systems and the applications that make those control systems work. Control systems are present in multiple industries including manufacturing, healthcare, and public utilities just to name a few. When an app that sells t-shirts, experiences an operational failure, customers just need to wait a bit longer in order to get their t-shirts. But when a control system experiences an operational failure, people could get hurt, even killed. If you're performing an operational risk analysis on control systems and applications, you'll want to pay close attention to those risks that threaten the safety of the people who rely on those apps to work exactly as they're supposed to. Impact scores for safety risks tend to be much higher than impact scores for other operational risks. After all the cost to recover from a few hours of app downtime, hardly compares to the unrecoverable loss of a life. For more insight into assessing safety criticality for control systems and applications, I recommend that you check out NIST Special Publication 800-82 Revision 2. The Guide to Industrial Control System Security. Section three of this publication, contains info you'll find invaluable when you find yourself performing this type of risk analysis. Performing an operational risk analysis helps you proactively identify and mitigate risks before they can have a negative impact to your app's performance. Your goal should be to move from performing occasional or ad hoc operational risk analysis to make this a continuous process.