From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Defense in depth

From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Start my 1-month free trial Buy for my team

Defense in depth

“

- [Narrator] Complex applications often present a broad attack surface to criminals and protecting each and every attack they throw your way can be very challenging. You'll quickly learn that no single security control is going to be able to stop every one of these attacks. That's why the principle of defense in depth is so important. When you apply this principle of defense in depth to your applications, what you're doing is you're identifying and implementing a set of complimentary security controls. If no single control will stop every attack, then why not layer those controls in a way that will have the desired effect? The concept of defense in depth is often compared to castle defenses from the Middle Ages. Think for a second about all the controls you would need to compromise. In order to steal gold from the castle keep, you would need to cross the moat surrounding the castle, maybe climb the hill where the castle sits, and then either scale the outer walls or sweet talk your way past the guards at the gate. Then you'd need to make your way through the streets surrounding the castle, avoiding guards all the way before you even get to the castle keep. If you make it that far, you'll still need to contend with the keep guards before you even make it to that last locked door that stands between you and the gold. That's a lot of controls to be bypassed or compromised, and that my friend is defense in depth at its finest. When applying these controls to your apps, a great place to start is with form fields. These fields offer your users a way to interact with the application, and you better believe the attackers are keenly aware of the damage they can do by abusing one or more of these fields. For starters, any attacker worth their salt is likely to launch protocol-based injection attacks against your app using those form fields as their entry point. While SQL injection attacks are the most popular, they're not the only type of injection attack you should be concerned with. LDAP injection attacks could expose user or directory information, and XML or XPATH injection attacks could result in a data compromise. In addition to protocol based injection attacks, you also need to be vigilant of structured attacks, cross site request forgery, cross site scripting, and operating system command injection attacks are all in scope. One of the first and arguably most effective layered security controls you should implement is input validation on these form fields. Don't trust anything your users send to your application, not without checking it first. If you allow your app to pass user supplied input directly to a database interpreter or to the operating system, you're leaving the gates wide open for the attacker to come in and do whatever they want. Your logging and monitoring controls are another layer of defense that you should put in place. Even though your input validation controls will reduce the likelihood that an attacker will be able to compromise your application, you'll have no idea the attacker is targeting you unless you're logging and monitoring system tells you so. If you alert on potential injection attacks, then you can take additional steps to shut down the attacker before they find a way around your controls. Security zones are another critical layer in your defense in depth control set. When you implement security zones, you essentially separate systems or data sets from one another in a way that proactively contains a potential incident. You can determine what these zones should look like. Based on the application's data classification. It's likely that your app data can be classified into one of three buckets. Public, internal, or regulated. Public data lives in one zone. Who cares if the attacker can see that data? It's meant to be accessible to everyone. Internal data should be behind a login page. That way an attacker would need to compromise a control, like stealing user credentials in order to see that internal data. If the data is regulated though something like medical records or credit card numbers, then you put that data behind an additional layer of controls. Maybe that part of the application is protected by two factor authentication and maybe the backend database lives behind a separate firewall. When you build your apps with the principle of defense in depth in mind, you make it a lot harder for attackers to get to the stuff you really care about.

Contents