Identifying Common Cybersecurity Vulnerabilities: A MindMap Guide
Download FREE Audio Files of all the MindMaps
and a FREE Printable PDF of all the MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript
Introduction
Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to Vulnerabilities in Domain 3, to understand how they interrelate, and to guide your studies.
This is the fourth of 9 videos for domain 3. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.
Vulnerabilities in Systems
Vulnerabilities inevitably arise when building and operating complex systems. It’s easy to have a vulnerability in a single line of code, let alone hundreds, thousands or even millions of lines of code, and numerous interconnected systems.
As security professionals, it is important for us to understand where vulnerabilities typically occur and how to design and develop systems to prevent these vulnerabilities.
We must ensure that the people involved in the design, development, deployment and operational processes have the right knowledge and training.
Accordingly, we are going to talk through a series of common vulnerabilities in systems and how to prevent them.
Single Point of Failure
Starting with single points of failure, which are non-redundant parts of a larger system, and if one of these single points of failure – fails, then the entire system stops working. A good example would be having a single router or single firewall which all traffic must pass through to-and-fro from the internet. A single firewall or router failing would result in all access to the internet being lost.
Redundancy
How do we prevent such single points of failure? Redundancy. We don’t just have one firewall, we have at least two, and they are configured and interconnected in such a way that the failure of one does not result in the entire network losing connection to the internet. We can also have redundancy in software, services, providers, and people.
Bypass Controls
The next vulnerability: bypass controls which are methods intentionally built into a system which allow a security control to be bypassed or circumvented. A good example is the configuration reset button on the back of a network device. You use a paper clip or a pencil to hold the button down for 5 or 10 seconds and then the device is reset to factory default and the current Administrative password is forgotten. Bypass controls are intentional, and they are created for good reason, but they certainly introduce risk by allowing security controls to be circumvented.
Mitigating Controls
To deal with the risk introduced by bypass controls we need to ensure additional mitigating controls are implemented to reduce the risk to an acceptable level. In the example of the reset button on a network device, the way we reduce the risk of an unauthorized person wielding their bent paperclip to pwn the network is to have physical security controls. Ensure that only authorized individuals can get near the network device and thus reduce the risk of unauthorized usage of the bypass control. The mitigating controls can be all sorts of things: physical security, enhanced logging and monitoring, segregation of duties, etc. it all depends on the nature of the bypass control.
TOCTOU (Race Conditions)
TOCTOU, Time of Check Time of Use, also known as race conditions, is a type of vulnerability where an application checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the application to perform invalid actions. In other words, an attacker attempts to race in and change a resource (a file, a variable, or some data in memory) between when the resource is checked and used.
Increase frequency of Re-authentication
There are numerous rather technical ways to reduce the risk of TOCTOU vulnerabilities: exception handling, transactions which provide concurrency controls, file locks, etc. But the answer you should look for on the CISSP exam is rather simple: increase the frequency of how often a check is performed to ensure access is appropriate, thus reducing the window of time in which an attacker can race in and do something they aren’t supposed to.
Emanations
Emanations are any sort of radio waves, electrical signals, light, sounds, vibrations, etc. that radiate from a system and can be intercepted to eavesdrop on the system, and thus allow the leakage of information. Emanations are a vulnerability that needs to be addressed and there are three major methods to do so:
Shielding (TEMPEST)
Shielding is various methods to block the emanations from a system so that they cannot be detected. You can block electromagnetic fields with faraday cages, sound with insulation, light with opaque walls. A type of shielding developed by the military is known as TEMPEST and it is specifically designed to shield devices that emit electromagnetic radiation. So just remember TEMPEST is a method of shielding.
White Noise
The next method that can be used to reduce the risk of emanations is white noise. White noise is blasting out strong random signals and thus drowning out the weak emanations from a secure device in the sea of white noise.
Control Zones
And finally, controls zones, which means placing high-value systems in physically secured zones. Essentially, put in place physical security controls to ensure only authorized individuals can get near a high-value system and thus prevent an attacker from getting close enough to detect the emanations from the system.
Covert Channels
The next vulnerability is covert channels which are unintentional communication paths that can unintentionally disclose confidential information. There are two major types of covert channels: Storage & timing
Analysis & Design
Covert channel vulnerabilities can be addressed by careful analysis of systems and processes to identify these unintentional communication paths and design controls to prevent or mitigate them. The predictive power of pizza deliveries is a great example of a covert channel. Add a comment below if you get that reference.
Aggregation & Inference
Aggregation and inference are vulnerabilities that occur whenever you aggregate, collect and centralize a lot of data in one location, think data warehouse, or big data – data lake. The major vulnerability is unauthorized inference. Someone may be able to infer, to figure something out, that they are not supposed to.
Polyinstantiation
To reduce the risk of unauthorized inference, you can implement the concept of Polyinstantiation, which means that different versions of the same information or process can exist at different classification levels. In other words our would-be attacker can only see their version of a process or a row in the database. Other versions can exist containing different information but they are invisible thus preventing unauthorized inference.
Mobile Devices
Mobile devices are considered a significant vulnerability due to the simple fact that they often contain a significant amount of sensitive information and they are mobile. They get forgotten on all sorts of different seats: taxi, train, airplane and latrine. And a misplaced or stolen mobile device has been the source of many a privacy breach.
Policy, training & procedures
An excellent way of reducing the risk of wayward mobile devices, is to have clearly defined policies regarding the acceptable use of mobile devices: and specifically requiring that sensitive data not be stored on mobile devices or severely limited. And having training and procedures in place to ensure the acceptable use policy is followed by employees.
Remote access security
Mobile devices are inherently taken away from the office and used in remote locations. Connections from mobile devices back into the corporate network should be encrypted to ensure the protection of sensitive data in transit.
End-point security
And the security of the mobile device itself, the end-point as it were, should be considered. Controls such as strong authentication, whole drive encryption, and remote wipe can be used.
OWASP Mobile Top 10
The Open Web Application Security Project (OWASP) has developed a top 10 list of the most common security flaws & vulnerabilities in mobile devices. As security professionals we must ensure that the following common vulnerabilities are addressed in system design, development and operation.
M1: Improper Platform Usage
Improper Platform Usage means that the security functionalities built into the mobile device, things like TouchID, FaceID, and Keychain, are not used or are used incorrectly. To prevent this vulnerability: secure coding and configuration management.
M2: Insecure Data Storage
Insecure Data Storage means that sensitive data, such as PII, is stored in insecure directories on the mobile device. Data in such directories can be trivially accessed if an attacker gets physical access to a device (that’s a nice way of saying they steal it) or the attacker writes malware which can copy the data out of the insecure directory and send it back to the attacker. The best way to avoid this: don’t store sensitive data on a mobile device.
M3: Insecure Communication
Insecure Communications refers to the fact that most mobile devices will communicate with a server across the super sketchy internet: any such data in transit could potentially be intercepted and read by an attacker. To secure data in transit: encrypt it using protocols like SSL/TLS and authenticate the server with certificates.
M4: Insecure Authentication
Insecure Authentication refers to an attacker figuring out how a mobile application calls the back-end server it is connected to – and once the attacker figures this out they bypass the app and send requests directly to the server, bypassing the authentication mechanisms built into the mobile app. To prevent this vulnerability, perform authentication on the server side
M5: Insufficient Cryptography
Insufficient Cryptography means a mobile device is using a crappy encryption algorithm, and/or the algorithm was poorly implemented. The rather obvious way to avoid this is to use good algorithms that withstand the test of time and implement them properly.
M6: Insecure Authorization
Authorization is where a system determines what functionality a user will be allowed to access. The Insecure Authorization vulnerability, therefore, refers to doing a poor job of this authorization step potentially allowing an attacker to bypass the authorization and/or grant themselves access they are not entitled to. To prevent this vulnerability: authorization should be performed by the back-end server, and not the mobile device, and the server should verify that any requests from a mobile device are permissible based on what the user is authorized to access.
M7: Client Code Quality
Client Code Quality refers to software running on a mobile device that is vulnerable to common attacks like memory leaks and buffer overflows. These weaknesses in the mobile software are exploited using malware or phishing. To prevent: write more secure code. Developers must be knowledgeable and trained to use secure coding practices and write secure code. Which is a lot less common than you would hope.
M8: Code Tampering
Code Tampering refers to an attacker changing or adding new malicious code into a mobile application allowing them to do fraudulent things like steal identities. To prevent: mobile applications must be able to detect if their code has been tampered with at runtime.
M9: Reverse Engineering
Reverse Engineering refers to an attacker carefully analyzing a mobile app to reveal information about back-end servers it is connected to, reveal problems or weaknesses with the crypto, steal intellectual property, etc. To prevent: use code obfuscation tools. I talk about the different types of code obfuscation in first video of domain 8, which I’ve linked to
M10: Extraneous Functionality
And the final OWASP top 10 mobile vulnerability: Extraneous Functionality which refers to an attacker carefully analyzing an application to find hidden functionality left behind by a developer. This hidden functionality will often allow the attacker to figure out how to gain unauthorized access to back-end servers. To prevent: make sure extraneous functionality is removed before an app is published by doing things like manual code review.
Web-based Vulnerabilities
All right now let’s talk about web-based vulnerabilities. A huge, and growing, percentage of applications are now web-based and thus, the common vulnerabilities in web-based systems is an important topic on the CISSP exam.
Cross Site Scripting (XSS)
We’ll start with cross site scripting: these are attacks in which malicious scripts are injected into otherwise benign and trusted web sites and a visitor's browser will download and execute the attacker's script. Essentially allowing an attacker to run code on victim’s machines which allows the attacker to do things like exfiltrate data. There are three major flavors of XSS.
Stored (Persistent)
We’ll start with Stored Cross Site Scripting. An attacker discovers a vulnerable website, and injects their code into the web application in such a way that the code is stored on the server and then displayed to every subsequent user that visits the webpage. This can be achieved by the attacker simply entering a comment on a website that has some sort of forum or comments section. And rather than the attacker adding some pithy comment about how someone else’s opinion on this is wrong, they enter javascript code in the comment field and hit submit. The attacker’s comment, the code, is stored on the server, and every subsequent user’s browser is going to download the HTML page with the javascript code embedded in it, parse the page, and execute the malicious javascript code. Stored XSS is persistent – every subsequent user will download and execute the injected code.
Reflected (Most common)
Reflected cross site scripting works a little differently. The malicious code from an attacker is only reflected back to one specific user. Here’s how this can work: an attacker sends the victim an email, perhaps as a phishing attack, and contained within the email is a link, a URL (Universal Resource Locator), and the URL contains some malicious javascript code. The user clicks on the URL sending the request to the server. The server then displays a webpage to the user that contains the malicious code from the URL – effectively reflecting the malicious code back to the user, and the user’s browser dutifully executes the malicious code. That’s a wildly oversimplified explanation. Let me know in the comments if you want me to create a deep dive video on this.
You should remember that reflected XSS is the most common form of XSS.
DOM
DOM, which stands for Document Object Model, is a much more technically complicated way of achieving XSS and it is rare. Accordingly, I wouldn’t worry about it for the exam.
Target of Attack: Client
The final piece that is important to think about for XSS is ultimately, who is the target of attack? And the answer is the client. The user’s browser is what the attacker is targeting.
Cross Site Request Forgery (CSRF)
Ok, next common web-based vulnerability: Cross Site Request Forgery (CSRF). This is where an attacker forces or tricks a user into executing unwanted actions on a web application in which the user is currently authenticated. Effectively allowing an attacker to execute authorized commands on a server. Again, that's a rather wildly oversimplified explanation.
Target of Attack: Server
Who is the target of attack in cross site request forgery? The attack passes through the user, and may negatively impact the user, but ultimately the target of attack is the server.
SQL Injection
SQL Injection. SQL - Structured Query Language is the language used to communicate with databases. A web application can send SQL commands to a back-end database to verify if a user’s username and password are valid, to store new data in the database, or to retrieve data from the database. The database is where the web application stores a lot of its data, and a user should not be able to directly command and control the back-end database.
In SQL Injection attacks, that is exactly what is happening. An attacker sends some SQL code to the web server, and then the web server passes that SQL code on to the database allowing the attacker to control the database. Not good.
SQL injection can be achieved by an attacker entering text in a form field, such as a username and password, and submitting the text to the web server. The web server then sends the supplied username and password text to the database as part of a SQL command. And if the web server hasn’t validated the provided text, then it could be allowing SQL injection attacks to occur.
Input Validation
How, then, do we prevent SQL injection attacks? Input validation. The web application should never allow SQL code from a user to be passed directly to the database. The web server must validate all input: sanitize the input by removing special characters, or escaping them.
Here is a big hint for the exam. You will likely see very technical questions on SQL injection or XSS, and equally technical answers to choose from. But if you boil them down, the answer you are almost always looking for is that the user’s input has been validated in some way. Sanitized.
Client Side vs. Server Side
As this is such an important topic, let's dig into a few techniques and best practices for input validation. First, where should the input validation be performed? Client side on the user’s browser, or server side? The answer is emphatically Server Side. It is trivially easy for an attacker to bypass client side validation - so for security purposes input validation must always be performed server side.
Client side / server side
Allow list / deny list
Allow Lists vs. Deny Lists
Second, a couple of techniques for input validation are Allow Lists and Deny Lists. An allow list means only specific characters will be permitted / allowed and all other characters will be blocked. Deny lists are the inverse of this. Only specific characters are blocked or removed and all other characters are allowed. Which is more secure? Allow lists. Allow lists are far more restrictive as you are only allowing specific characters and everything else is blocked.
A quick comment on terminology here. Historically the terms white lists and black lists were used here, and you may still see that terminology on the exam which is why I’m mentioning. Allow lists are the equivalent of white lists, and deny lists are the equivalent of black lists. I strongly support moving towards using the terms allow lists and deny lists instead.
And that is an overview of Vulnerabilities within Domain 3, covering the most critical concepts you need to know for the exam.
Do you have a busy schedule? Only a limited amount of time to study? Are you struggling to find the best study resources and cobble together various, often contradictory material from different sources?
We have the solution for you. Our CISSP MasterClass provides all of the study material you need to confidently pass the CISSP exam.
We make it as easy as possible for you to efficiently achieve your CISSP certification.
You can learn all about our CISSP MasterClass and enrol here: destcert.com/CISSP
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!
