1. Home
  2. Training Library
  3. CISSP: Domain 3 - Security Architecture & Engineering - Module 5

Assess and mitigate vulnerabilities in mobile systems

Start course
Overview
DifficultyAdvanced
Duration37m

Description

Course Description

This course is the 5th of 6 modules of within Domain 3 of the CISSP, covering security architecture and engineering

Learning Objectives

The objectives of this course are to provide you with and understanding of:

  • Common attacks against cryptography
  • How to assess and mitigate vulnerabilities in web-based systems, discussing suggested protections, XML, SAML and OWASP
  • How to assess and mitigate vulnerabilities in mobile systems, discussing risks from remote computing and risk for mobile workers

Intended Audience

This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.

Prerequisites

Any experience relating to information security would be advantageous, but not essential.  All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Feedback

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

Transcript

We're going to move into section 10, now, where we are going to assess and mitigate the vulnerabilities in mobile systems. Mobile being a very, very active portion, portion of our systems these days, and of increasing importance, even so. 

So, we're going to look at risks from remote computing and risks for mobile workers. Now, risk from remote computing, may seem like an obvious statement. But, as we find many users still cause these kinds of problems through either trust that is misplaced, or poor usage or poor computing hygiene. Now, the VPN, as we know, are encrypted tunnels. And what they do is they ensure encryption and security of confidentiality for data in motion. Of course, providing that they're properly secured with strong ciphers and other good computing practices. However, users trust these, first by not necessarily understanding them well, as to what they do and what they don't do, because they do have their limitations. 

A VPN does not ensure that remote and mobile devices themselves are free from software and configuration vulnerabilities. Which, of course, could be used to propagate viruses or worms, or in some other way compromise the overall security that the user believes they're getting out of employing the VPN. And the end point device risks include things like trusted clients. Now, trusted clients means that we know that it doesn't have an unknown configuration, that it has known attributes, and they are set in a proper way. And we have to decide for our own use, our own enterprise, what we mean by the term trusted. In other words, the specific parameters that bring trust to the level that we accept as trusted, in our particular context. 

We have network architectures. And our risks are, what are the configurations? What are those things that we are accepting in the way of devices that attach to us? And what are we accepting when we attach to those? What countermeasures do we need? What countermeasures do they have? What about policy? How has it been defined? What things of the policy have been appropriately implemented? What things are operating? What things have been left out? When was the last time it was tested? All of these questions need to be asked and answered. And if they cannot be answered, we as user connecting to some site, with no contact to any person there, and of course, they're going to be loath to reveal any of this stuff to us. It is going to be an unknown for us to connect to them. Therefore, we do have control over, we should be sure that we've got all the right features installed and configured properly to operate on our device. And then of course, we have the unavoidable, stolen or lost device. 

These small devices, like phones and tablets, are lost with frightening frequency. It is not necessarily common, but it is eventual and unavoidable that this will happen. And that means we have something in the way of compensating controls that we have to employ. When the device is known to be lost or stolen, we then have to notify our people back at our shop to say, "I've lost the device, it's been stolen, "I have no idea what happened to it." So that they can then take the next set of steps that they need to, such as remote wipe, such as remote deactivation. So that they can adapt to a threat that is now present, that wasn't present five minutes before. The mobile worker risks include platform proliferation. 

If a remote worker is based at home, the question has to be asked, how many other devices do they have attached to their wireless access point at home? And do those pose any risk to any of our operations? What about the general security of where they're working? Not necessarily home, but perhaps a hotel room when they're out on the road. We also have all the home-based PCs, the multi-device sync solutions that are out there. And the fact that a device belonging to the employee is also going to be used to access without any modification, whatever the corporate resource that they're going to work with from home. All of these conditions raise questions about just how much security there is at that remote site, where the mobile worker is. And by them connecting with us, wherever they happen to be, whether it's across town or across the country, or even from a foreign country. That is where our enterprise's security perimeter now sits. And there may be an awful long distance between them and us. 

Now, the potential attack vectors from mobile devices include SMS messaging, WiFi, Bluetooth, and in rare instances, infrared as connect methods with varying levels of security. We have USB. As we know, Stuxnet malware was communicated using a USB thumb drive. We have web browser, email client, third-party applications, and all of the unrevealed configuration details and actions that they may take. We have physical access, such as happens with theft or loss. There may be operating system vulnerabilities in a given platform due to a lack of patching or simply a vulnerable operating system. And then we have one of the questions that rarely gets asked because the people don't just ask the question, since they don't know. 

We have jail broken phones. Typically, this is about the iPhone, and someone putting in an iPhone jailbreaking kit, which can be bought for commercial price on the web. But it's a risk that we don't know about. We're unaware, meaning we can't even quantify what this might be. So, we have to remember to ask the question. Useful standards that we can employ to improve how remote workers and mobile technology can be secured include these from NIST. The SP 800-40, the Guide to Enterprise Patch Management Technologies. The SP 800-121, Guide to Bluetooth Security, and as skeptical as anyone might be, the guide does indeed have additional suggestions for how to protect in the Bluetooth usage. And Special Publication 800-124, Guidelines for Managing the Security of Mobile Devices in the Enterprise. NIST also has a guide on how to employ VPNs more securely than simply to take them and set them up with the default parameters that the vendor may offer. And these guides should be used. 

We've come to the conclusion of this particular chapter of domain three. We're going to start again, the next chapter, with assessing and mitigating vulnerabilities in embedded devices and cyber physical systems. So, please join us again for that next chapter. Thank you.

About the Author

Students285
Courses13
Learning paths1

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.