Once you select a unique functional architecture for your application, you need to select and prioritize the right controls for that architecture. In this video, learn how to identify and controls for the app, including controls associated with the hardware platform.
- [Instructor] Once you select a unique functional architecture for your application, you'll need to select and prioritize the right controls for that architecture. Before you can implement any of those controls, though, you first need to figure out which ones are most appropriate for your app. The process of control identification is as important as it is tricky. Based on the results of your attack, surface evaluation, and threat modeling efforts, you may have already identified controls that would effectively address all the threats in your list. That doesn't mean you can afford it though. Controls can be costly to implement and costly to maintain, in terms of both money and time. Your job is to figure out the right controls for your app based on the resources you have at your disposal. All of this activity is designed to reduce risk. Speaking of risk, there's a simple formula you can use to help prioritize both your risks and your controls. Risk equals likelihood times impact. Likelihood measures how confident you are than an attacker might damage your app. And impact measures how bad that damage might actually be. By building a scale for each of these measurements, say one to five, you can multiply those two numbers together to get a risk score. The higher the risk score, the higher the control priority. Once you've identified and prioritized those risks, you'll have a few options for how you can address them. If a risk is relatively low, you might choose to accept it. This option is common when the cost of the control far outweighs the value of the asset. You could choose to reject a risk by taking action that eliminates it all together. If an open source component has a critical vulnerability, you might choose to rewrite the app so that it no longer uses that component. You might choose to share a risk by tapping into another team's resources or budget to help in implementing a control. Instead of sharing a risk, you might choose to transfer it to that other team entirely. If you hired a third party team of developers to write your app, you might leverage your contract with them to make sure that if the vulnerability isn't fixed, they're the ones responsible for the damages. Finally, you might choose to mitigate a risk. This is the option most CSS LPs want to explore first. If there's a way we can fix the issue, let's follow that path and see where it leads. As you come up with ideas for ways to protect your app, keep in mind that some of the controls you want to use may already exist somewhere in your organization. User credentials are a perfect example. If your app requires that users have their own unique logins, that means that someone needs to build a system for creating user accounts, assigning passwords to those accounts, and managing changes to those credentials over time. Why would your app team spend time building their own user directory when they could instead just tell their app to point to your existing instance of Active Directory? There may be valid reasons that you need to keep those directories separate. But you should try to leverage existing controls first before deploying a new set of controls and adding complexity to your environment. When you apply this approach to your control, identification and prioritization efforts, you'll notice how things seem to fall in place. If your app is a public-facing marketing app with no user credentials and no sensitive internal information, then encryption is a lower priority than it would be for an app that processes sensitive information. If your app contains functions designed for administrators and power users, then role-based access controls or access control list will help you ensure that regular users don't accidentally or intentionally abuse those functions. If you already have a centralized directory for all user accounts, your developers can point to that directory instead of building their own so your security team's attention isn't divided among too many user repositories. Apply this risk-based approach to identifying and prioritizing controls, and you're much more likely to find the set of controls that's right for your app and for your organization.
- Threat modeling
- Identifying and prioritizing controls
- Cloud architectures
- Component-based systems
- Designing network, sever, and data controls
- Secure design principles and patterns
- Data modeling and classification